Is Lovable secure? The one setting that decides it

Lovable isn't insecure. But a Lovable app can be wide open, and the difference is one setting most builders never touch. The honest answer to "is Lovable secure?" is: it depends entirely on what you did after it generated the app.

This isn't hypothetical hand-waving. The gap has a CVE and a headcount attached to it. Here's how Lovable apps are wired, the exact place they leak, and how to check yours.

How a Lovable app is put together

Lovable generates a frontend and, for anything that needs to store data, wires it to Supabase — a hosted Postgres database. To talk to that database from the browser, the app ships with a Supabase anon key baked into the frontend.

That key is public by design. Every visitor has it — you can read it out of the page source. It's only safe because it's supposed to be fenced in by Row Level Security: database rules that decide which rows each user is allowed to touch. No RLS, no fence.

The gap that hit 170 projects

Here's the trap. Supabase turns RLS on automatically only when you create a table through its Table Editor. Tables created any other way — raw SQL, a migration, or an AI tool writing the schema for you — don't get RLS by default. And an AI builder writes a lot of schema for you.

So the public key ends up pointed at tables with no fence around them. Anyone who opens the app, grabs the key, and queries the database reads every row — other users' emails, private records, the lot.

CVE-2025-48757

the 2025 disclosure of this exact RLS gap in Lovable apps

10.3%

of analyzed Lovable projects had tables readable by anyone

Table Editor

the only path where Supabase enables RLS for you

anon key

public by design — safe only when RLS is on

Those figures come from a 2025 disclosure by security researcher Matt Palmer (CVE-2025-48757), who found hundreds of endpoints across scanned Lovable projects returning data to unauthenticated requests. The point isn't that Lovable is uniquely bad — it's that the default is "works," not "locked down," and the two look identical from the front end.

The other key you must never ship

Supabase gives you a second key, the service_role key, which bypasses RLS entirely — full read/write on everything. It exists for trusted server-side code.

Making your Lovable app actually secure

1. Enable RLS on every table in the public schema. Don't assume it's on — check each one. Anything created outside the Table Editor is guilty until proven otherwise.
2. Write real policies. RLS on with an "allow everyone" policy is no better than off. Each policy should tie rows to the user, e.g. auth.uid() = user_id.
3. Keep the service_role key server-side. Never in client code. Grep the frontend for it.
4. Move any other secrets out of the bundle — third-party API keys, payment secrets — into server-side env vars.
5. Check the outside view too — security headers, SSL, cookies — the defaults an app builder rarely sets.

The fastest way through the database side is to make the AI check its own work, table by table:

My app was built with Lovable and uses Supabase. Audit it specifically for the Row Level Security gap that Lovable apps commonly ship with.

1. List every table in my public schema and tell me, for each one, whether Row Level Security is ENABLED. Flag any table that has RLS off — those are readable/writable by anyone with the public anon key.
2. For each table that has RLS on, show me its policies and tell me plainly whether they actually restrict rows to the owning user (e.g. auth.uid() = user_id), or whether a policy is effectively "allow everyone".
3. Check where my Supabase keys are used: confirm the service_role key is NEVER used in client-side / browser code, only the anon key. Flag any client init that uses the service role key.
4. Point out any table that was created via SQL, a migration, or generated code rather than the Table Editor — those don't get RLS automatically.

For each finding give me the table name, the risk in one sentence, and the exact SQL to enable RLS and add a correct policy.

Lovable's own Supabase integration docs cover connecting the two; the RLS discipline above is the part that's on you.

The half you can check from outside

RLS lives in your database, but the headers, certificate, and cookies live on the public URL — testable in seconds without touching code:

This is the Lovable-specific cut of a broader problem — the same class of gaps runs through every AI-built app, which we lay out in vibe coding security risks.