How to choose a security scanner for a Lovable app

A scan that only gets your address reads the same files a browser downloads. That is enough to find:

• Secret keys in your JavaScript (OpenAI, Stripe, the Supabase service_role key).
• Source maps that rebuild your original code.
• Files left public, like .env, .git or database dumps.
• Missing security headers, HTTPS problems, unprotected cookies and open CORS.

It can’t see whether your tables have RLS, what your edge functions check, or whether one user can read another user’s data. A clean result means the common outside mistakes aren’t there, not that the app is secure.

Scans are either passive (they only read pages, like a visitor) or active (they send crafted requests to find weak spots). Only run an active scan against a site you own, and preferably on a copy rather than your live app.

To know which tables a stranger can read, a tool has to query your Supabase project with the public anon key, the way an attacker would. You can do it yourself in a few minutes with our Supabase RLS guide.

Lovable also has a security scan in the editor, which reviews your project from the inside. Run it, and still test from the outside, because each sees things the other can’t.

If you use a third-party tool for this, prefer one that asks you to prove you own the site before testing it, and that counts rows instead of downloading them. Your users’ data shouldn’t end up in a vendor’s database.

If your Lovable project is connected to GitHub, a code scan on each change catches problems before they ship: secret keys committed to the repository, dependencies with known vulnerabilities and migrations that create tables without RLS. It also catches things a URL scan never sees, like keys used only on the server that were committed by mistake.

• Does it store your code or your pages, and for how long?
• What does it do with a key it finds? It should mask it in the report and never use it.
• Does it ask for write access to your repository, and does it really need it?
• Does it check that you own a site before testing its backend?
• Does it say clearly what it doesn’t check? A scanner that claims to catch everything is overselling.

Never give a third-party tool your Supabase service_role key. It ignores RLS, so a tool holding it sees and can change everything, and the test wouldn’t tell you what a stranger sees anyway.

• Sign up with two test accounts and check that the second can’t read or change the first one’s data, in the app and through the API.
• Check your business rules: prices, credits, limits and roles must be enforced on the server, not only in the browser.
• For an app that handles payments, health or other sensitive data, add a review by a security professional.

Our free scan is a passive URL scan: it finds leaked keys, exposed files and missing headers in about a minute, with no account. Our code scan checks your GitHub repository on every push and pull request, free for public repositories and 2 private ones a month. Our backend check tests which Supabase tables, storage buckets and API routes a visitor with no account can read, after you prove you own the site, counting rows without downloading them: once a month on the free plan, weekly on Pro. None of them signs in, so the two-account test above is still yours to do.