Is Lovable’s security scan enough on its own?

It is a good start and you should fix what it finds. It reviews your project; it doesn’t use your published app as two different people. Test the live app as well, by hand or with an outside scanner.

Does Lovable’s Quick scan check row level security?

Yes. Per Lovable’s docs it flags tables without RLS, access rules that let everyone through, and leaked-password protection being off. Whether a policy correctly limits each user to their own rows is a behavior question, best answered by a cross-user test.

Is the Supabase key in my Lovable app a leak?

Not if it is the anon or publishable key. It is meant to be public and RLS decides what it can do. A service_role or sb_secret_ key in the browser is a leak.

Will scanning change my Lovable project?

The free scan sends only GET and HEAD requests. The Proof Report writes rows marked preflight-canary-… as your test accounts and deletes them when your policies allow; any leftover gets a one-line DELETE in the report.

Does Preflight work with Lovable Cloud?

The free scan works on any published URL you can verify. The Proof Report needs a Supabase project and one SQL function to prove ownership, which Lovable can add as a migration.

Lovable security scan

Is my Lovable app safe? Start with Lovable’s own scans, then test the published app the way a stranger would. Here is what each one covers.

Run the free scan See a sample report →

Free scan: GET and HEAD requests only, after you verify you own the domain. The two-account cross-user test is the $29 Proof Report. Updated 25 Oct 2026

In short

✓Lovable runs a Quick scan every time you publish and offers a manual Deep scan of your code. Both are free to run.
✓They review your project. They don’t sign up to your live app as two people and try to read each other’s data.
✓Most real leaks in Lovable apps are Supabase access rules: tables anyone can read, or rows any signed-in user can read.
✓Run Lovable’s scans, then test the published app from outside. The steps are below.

01What Lovable’s built-in security scan checks

As of 25 Oct 2026, Lovable’s security documentation describes two layers:

Quick scan runs automatically when you publish. It reviews your database (tables without RLS, access rules that let everyone through, leaked-password protection turned off), checks your npm dependencies for known vulnerabilities, and flags an MCP server exposed without authentication.
Deep scan is manual (scheduled on Enterprise). It reads your app’s code for access control problems, unauthenticated endpoints, injection, leaked secrets, payment and auth logic, and exposed data.
Fixes: many findings come with a one-click fix. Asking the agent to “review my app’s security” in chat uses credits; the scans themselves don’t.
Connectors: you can add Wiz for static analysis or Aikido for AI-driven attack testing, billed by Aikido.

That is a solid baseline, and you should run it. Lovable itself says these tools don’t catch everything.

02What a project scan can’t see in your live app

A scanner that reads your code and database settings answers “does this look right?” Some problems only show up when you use the published app as a stranger:

Policies that look scoped but aren’t. to authenticated using (true) or auth.uid() is not null names a role, so it reads as “protected”. With open sign-up, it lets anyone read every row. Only a cross-user test proves it either way.
Changes made outside Lovable. A table or policy added in the Supabase dashboard, a migration from another tool, or a setting flipped later.
What actually ships. Environment variables end up in the deployed JavaScript if the code reads them in the browser. The live bundle is the source of truth.
Your domain. Files like /.env or /.git/config served by a custom host, missing headers, an expiring certificate.

This is not hypothetical. In March 2025, researcher Matt Palmer found 303 endpoints with inadequate RLS across 170 of 1,645 Lovable projects he checked, and noted that Lovable’s scanner at the time checked whether RLS policies existed, not whether they worked (his statement on CVE-2025-48757). Lovable’s scans have grown a lot since. The lesson still holds: test behavior, not just configuration.

03How to check if your Lovable app is safe: 6 steps

1. Run both Lovable scans and fix every critical finding. Publish to trigger the Quick scan, then run the Deep scan from the security view.

2. Look at what your live site ships. Open the published site, then DevTools → Sources, and search the JavaScript for supabase.co, sb_secret_ and service_role. The anon or publishable key is supposed to be there (why that’s fine). A secret or service_role key is not: rotate it now.

3. Try reading your tables signed out. With the public key from step 2:

curl -I "https://YOUR_REF.supabase.co/rest/v1/profiles?select=*" \
  -H "apikey: YOUR_PUBLIC_KEY" -H "Prefer: count=exact"
# content-range ending in /0 means no rows visible signed out

4. Make two test accounts and cross between them. Sign in as A, copy the access token, and ask for B’s rows (the curl is in the RLS checker guide). You should get an empty list.

5. Try to upgrade yourself. If a profile row has plan, role or credits, try changing it as A. It should fail.

6. Check sign-up settings. In Supabase Auth, decide whether email confirmation should be on and whether anonymous sign-ins are needed. Anonymous users count as authenticated, so every “signed-in users can…” policy includes them.

04A prompt to fix what you find in Lovable

Be specific. Vague prompts like “fix security” tend to produce using (true).

For the table public.notes: keep row level security on. Replace all
policies with four: select, insert, update and delete, each "to
authenticated" and limited to rows where user_id = (select auth.uid()).
The insert and update policies must use WITH CHECK on the same
condition. Do not add any policy with "true" or "auth.uid() is not null".
Don't change anything else.

On Lovable Cloud, policies live under the database view of your project. If you connected your own Supabase project, you can also run SQL in its editor. Either way, run steps 3 to 5 again after the fix.

05Lovable security scan vs Preflight

Check	Lovable scans	Preflight
Reads your source code	Yes (Deep scan)	No. Outside only.
Runs on every publish	Yes (Quick scan)	No. Monitor re-runs the outside checks weekly.
Database rules: RLS missing or always true	Yes	Counts rows visible signed out (free scan)
Signs in as two users and crosses between them	Not in Lovable’s own scans	Yes (Proof Report, $29)
Tries to raise its own plan or credits	Reviews logic in code	Yes, then sets it back (Proof Report)
Secret keys in the deployed JavaScript	Looks for secrets in code	Yes (free scan)
Exposed files, headers, HTTPS, SPF and DMARC on your domain	Not described in its docs	Yes (free scan)
Dependencies and MCP server	Yes	Known-vulnerable libraries in the bundle only

They overlap less than you would think. Use Lovable’s scans while you build, and an outside test on the published app before you share it.

06Scan your Lovable app with Preflight

The free scan needs only your app’s URL and proof that you own the domain. It sends GET and HEAD requests, finds the Supabase project and key your bundle ships, and reports tables readable signed out, secret keys in the bundle, exposed files, headers, auth settings and storage buckets. It does not change anything.

The Proof Report needs two test accounts that sign in with email and password, and one line of SQL to prove the Supabase project is yours. On Lovable Cloud, ask Lovable to add that function as a migration if you can’t open a SQL editor. If the free scan finds no Supabase project, the $29 option isn’t offered.

?Questions people ask

Is Lovable’s security scan enough on its own?
It is a good start and you should fix what it finds. It reviews your project; it doesn’t use your published app as two different people. Test the live app as well, by hand or with an outside scanner.
Does Lovable’s Quick scan check row level security?
Yes. Per Lovable’s docs it flags tables without RLS, access rules that let everyone through, and leaked-password protection being off. Whether a policy correctly limits each user to their own rows is a behavior question, best answered by a cross-user test.
Is the Supabase key in my Lovable app a leak?
Not if it is the anon or publishable key. It is meant to be public and RLS decides what it can do. A service_role or sb_secret_ key in the browser is a leak.
Will scanning change my Lovable project?
The free scan sends only GET and HEAD requests. The Proof Report writes rows marked preflight-canary-… as your test accounts and deletes them when your policies allow; any leftover gets a one-line DELETE in the report.
Does Preflight work with Lovable Cloud?
The free scan works on any published URL you can verify. The Proof Report needs a Supabase project and one SQL function to prove ownership, which Lovable can add as a migration.

What an outside scan can't tell you

Can one user read another user's data?

Preflight signs in as two test accounts you create and tries to read one account's rows and files from the other. That cross-user test is the $29 Proof Report for Supabase apps. Start with the free scan: it checks your live app from outside with GET and HEAD requests only.

Run the free scan Pricing →