Lovable security: the most common vulnerabilities (and how to fix them)

Row Level Security, the most common blind spot

Lovable connects the project to Supabase and creates the tables the prompt implies (users, orders, messages...). Row Level Security (RLS) — the mechanism that decides who can read or write which row — isn't always configured correctly on the first pass: either it stays disabled on some tables, or an AI-generated policy uses USING (true) to make a feature "work" quickly, which amounts to having no policy at all.

Supabase's anon key is public by design — it's in the JavaScript sent to every visitor. Without correctly written RLS, anyone can use it to query Supabase's REST API directly and read (or write) the raw content of the tables, completely bypassing the interface Lovable generated:

curl "https://<project>.supabase.co/rest/v1/users?select=*" \
  -H "apikey: <anon key found in the JS>"

If this request returns rows a visitor should never have seen without being logged in, RLS isn't correctly configured on that table.

The preview link is public by default

The share link Lovable generates to preview an app in progress isn't protected by any authentication — whoever guesses it or gets hold of it (a link shared in a Slack channel, a ticket, an email) accesses the app exactly like a normal user, including the same RLS issues described above if the associated Supabase project isn't locked down yet. A project still in the prototyping phase, with real-looking test data, deserves the same level of caution as a site already live.

The fix

Enable RLS on every table as soon as it's created, with a policy that actually restricts access to its owner:

ALTER TABLE orders ENABLE ROW LEVEL SECURITY;

CREATE POLICY "users_read_own_orders" ON orders
  FOR SELECT
  TO authenticated
  USING (auth.uid() = user_id);

If you ask Lovable to add a feature that touches a new table, spell out in the prompt exactly who should be able to access it ("only the owning user can read/update their own order") rather than letting the AI guess — that's the difference between a correct policy and a USING (true) that silences the error without fixing the problem. Also check that the service_role key (the one that bypasses RLS entirely) never appears anywhere in code that runs client-side.

Full guide to the most common RLS pitfalls: Disabled or misconfigured Supabase RLS.

Got a Lovable app live (or in preview)? Scan it to check whether your Supabase tables are reachable without authentication.