If you built your app with Lovable, you have more security help than most founders had a year ago. After the CVE-2025-48757 episode, in which a researcher found 170 Lovable apps leaking data, Lovable added and expanded security scanning. It's worth understanding exactly what it does, so you know what's left for you.
What Lovable checks for you
According to Lovable's documentation, there are two scanners.
The basic scan runs automatically when you publish. It lints your Row Level Security policies, reviews the database schema and audits dependencies. It's quick, and it catches the most dangerous configuration mistake in Supabase apps: a table with no RLS at all.
The deep scan runs on demand. It includes everything in the basic scan and adds access control review, backend endpoint protection, code-level vulnerabilities and project-specific issues. It takes longer, and you should run it before every significant launch.
There's also a Security view in each project where you can see findings and apply fixes, and a workspace-level security centre on business plans. Lovable also detects some exposed API keys and pushes you toward storing them as secrets.
What Lovable says it can't do
The documentation is direct about this: "These tools help identify common security issues, but they cannot guarantee complete security." And: "You are responsible for ensuring that your app meets the security requirements appropriate for its use case, especially if it handles sensitive data or performs critical functions."
That's not legal boilerplate. It describes a real limit of any automated scanner looking at your project from the inside.
The gap: correct versus present
A scanner can check whether a rule exists. It has a much harder time checking whether the rule is right, because "right" depends on your business.
Say you have an invoices table. RLS is on, and there's a policy that lets any signed-in user read rows. The scanner sees RLS enabled and a policy in place. But in your business, a customer should only see their own invoices. That policy lets every customer read every other customer's. Matt Palmer made the same criticism of Lovable's first security scan: it checked for the existence of a policy rather than its correctness.
The deep scan's access control review is meant to catch more of this, and it may. But only you know that accountants should see all invoices for their clients and nobody else's, or that team members can read but not delete. The tool can't infer rules nobody wrote down.
A checklist for what's left
Work through this after the scans come back clean.
Read every policy in plain English
Open Supabase, go through each table, and for each policy write one sentence: "Customers can read their own invoices." If you can't, ask Lovable's chat to explain that specific policy. Watch for policies whose condition is just true, or that only check the user is logged in. Our RLS guide for founders explains what good policies look like.
Check file storage separately
Uploaded files live in Supabase Storage, which has its own rules. Upload a private file as one user, copy its URL, and open it in a private browser window while signed out. If it loads, so can anyone's. The Tea app leak was exactly this kind of problem.
Search your live site for secrets
Open your published site, press F12, go to Sources, and search all files for sk-, sk_live_, service_role and secret. The Supabase anon key is fine to find. Secret keys are not. We have a five-minute guide for this.
Try paid features from a free account
If you have plans or credits, sign up as a free user and try to use a paid feature by calling it directly rather than through the button. The check that unlocks it has to happen on the server or in a database rule, not in the React code.
Run the two-account test
Create accounts A and B. As A, create something private. As B, try to view, edit and delete it, through the app and by replaying the network request with A's ID. This single test catches most of the access problems a scan can miss. There's a step-by-step version in our guide to the "change the number" test.
Check what happens when you're signed out
Sign out and visit your app's internal pages directly by URL. Try the API requests you saw earlier with no session. Anything that works without a login should be something you meant to be public.
Where this leaves you
Lovable's scans are a good first line, and they'll catch the worst mistake. Treat a clean scan as a sign you're ready to test, not a sign you're done. The test takes an afternoon with the pre-launch checklist. Or, if you'd rather have someone else try to get in from the outside, that's what we do.