Is Lovable safe?

Is Lovable safe to ship?

Lovable turns a prompt into a working Supabase-backed app faster than almost any other tool. The question worth asking before you send traffic to it is whether the database behind that app is actually locked down.

Run the 60-second self-check →Or run the free Leak Check
Credit where it's due

What Lovable actually does well

Scaffolds a full working app, frontend, auth, and a real Postgres database, from a plain-language prompt in minutes.

Wires up the Supabase client library correctly, including session handling and the auth UI.

Iterates fast on follow-up prompts without breaking the parts that already work.

The gap

The gap: row-level security is off by default

Lovable creates your tables through its Supabase integration, but it does not ask whether those tables should be locked down before it ships them. Supabase's public anon key is meant to be visible in the browser, that part is fine by design. The problem is that without a row-level security (RLS) policy on a table, that same anon key lets anyone query it directly through the REST API, no login required. CVE-2025-48757 documented this exact pattern across 170 of 1,645 scanned Lovable apps. A separate scan of 66 live AI-built apps, covered in our data report below, found the same gap in 41% of the Supabase-backed apps tested.

60-second self-check

Check Lovable for this yourself right now

This takes about 60 seconds and does not require touching your Supabase dashboard.

  1. 01

    Open your live Lovable app and open browser devtools (F12 or right-click, Inspect).

  2. 02

    Go to the Network tab, reload the page, and find a request to a supabase.co domain.

  3. 03

    Click that request and copy the value of the apikey header, this is your public anon key.

  4. 04

    In a terminal, run: curl "https://<your-project>.supabase.co/rest/v1/<table-name>?select=*&limit=1" -H "apikey: <anon-key>"

  5. 05

    If rows come back, that table has no RLS policy blocking anonymous reads. If you get an empty array or a permissions error, it is protected.

Rather not do this by hand? The free Leak Check runs the anon-key probe and a client bundle scan against your live URL and gives you results in under a minute.

Run the free Leak Check →

Where the numbers come from

We scanned 66 live apps built with Lovable, Bolt, Cursor, base44, and Tempo. 41% of the Supabase-backed apps had at least one table anyone could read with the public anon key. The full methodology and findings are in the data report.

Read the data report →
FAQ

Common questions about Lovable security

No. Lovable correctly wires up Supabase, and the Supabase anon key is designed to be public in the frontend. The gap is not the tool, it is that Lovable does not enable row-level security on the tables it creates, and most builders never go into the Supabase dashboard to turn it on themselves.
No, that is expected and safe on its own. The anon key is meant to be public. What matters is whether row-level security is enabled on every table behind it. Run the self-check above against each table your app uses to confirm.
Open your Supabase dashboard, go to Authentication, then Policies, and enable row-level security on the affected table. Add a policy that scopes reads to the row owner, for example auth.uid() = user_id. Re-run the same curl command afterward to confirm it now returns an empty result.
Only apps that use Supabase as the backend, which is most Lovable apps by default. It also only affects tables where RLS was never explicitly enabled. Tables you or Lovable already locked down are not exposed.
Yes. The free Leak Check below runs this test, plus a scan of your client bundle for other exposed keys, against your live URL in under a minute.
Check another builder

Is your builder safe?

Is Bolt safe? →Is Cursor safe? →Is Replit safe? →Is v0 safe? →Is base44 safe? →