Lovable scanner
Your Lovable appis already public
The URL you published is reachable by anyone, including the parts of it that were never meant to be: the backend it talks to, the policies on that backend, and the keys that shipped inside its JavaScript. This scan reads all of it from the outside, in one pass.
- No agent
- Reads the live URL
- 85 checks in every scan
Why this shape of app
Generated code
solves the demo
A builder gets something working in an afternoon, and the working version is the one that goes live. None of the risk below is a Lovable fault — it is what happens when the last mile of a project is a security review nobody scheduled.
The bundle names your backend
Your Lovable app ships its Supabase project URL and publishable key in the JavaScript every visitor downloads. That is correct — the publishable key is designed to be public. It is also the map: it tells anyone where the data lives and which door to try.
Row-level security is the whole defence
With a public key, the only thing between a stranger and your users’ rows is the policies on the tables. So the scan asks the REST API for row counts with anonymous access and reports what answers — a table that returns counts to anyone is a table with no policy on it.
The service-role key ships by accident
The other Supabase key is not public, and it looks like the one that is. Put it in a NEXT_PUBLIC_ variable or import it into a client component and it is compiled into the bundle, where the scan finds it — and where anyone else will too.
Nobody wrote the headers
A generated app inherits its host’s defaults, which usually means no Content-Security-Policy, no HSTS, cookies without Secure or SameSite, and a wildcard CORS rule that also accepts credentials. Every one of those is a check, and every one is a line of configuration.
What runs on your URL
The checks that
bite hardest here
A shortlist, not a special mode: paste a Lovable URL and the whole scan runs. These are the checks that most often have something to say about an app like this.
- Content-Security-Policy
- Strict-Transport-Security
- Cookie security flags
- CORS policy
- Anonymous access to protected pages
- CSRF protection on state-changing forms
- Secrets in JavaScript
- Source maps
- Session credentials in browser storage
- File upload content validation
- Supabase row-level security
- Server-rendered content
Every one of these runs on every scan, whatever built your app. What each check looks at is on the full list.
The builder did not skip the security review. There was never one on the calendar.
Stated plainly
What this page
is not claiming
There is no Lovable check in the scanner. There is no platform-specific mode, no integration with the builder, and nothing here reads your Lovable account. It is the same 85 checks that run on every site, pointed at the URL you paste.
The scan sees the published app and nothing else. A policy you wrote but never deployed, a secret that only lives in your editor, an endpoint behind a login — none of those are visible from outside, and the report marks what it could not look at instead of scoring it.
It is not a penetration test. It never logs in, never submits a form of yours, never calls a state-changing endpoint, and refuses private and metadata addresses before a request leaves. The active checks against a backend run only on a domain you have proved you own.
A clean scan is not a security approval. It says these 85 things were fine on the day it ran, on the URL it ran against. The row your app writes to a table with no policy on it is the one check that actually matters.
How the scan runs
Three steps,
one URL
No agent to install, no DNS change, no access to your account. The scan reads the site the way a stranger does.
Step 1
Paste the URL you share
The one your users have, custom domain or generated subdomain. No account connection, no DNS change, nothing to install.
Step 2
It reads; it does not poke
One fetch of the page answers most of the list. Where a check has to make more requests there are budgets: a five-second cap per fetch, a handful of probes per scan, robots.txt obeyed throughout.
Step 3
Take the evidence and the prompt
Every finding carries what was measured — the header, the status code, the table name — and a prompt written for the same agent that built the app, so the fix is pasteable.
See what your
app gives away
Paste the URL and the whole list runs against it — the backend its bundle names, the keys it ships, the headers nobody set. About a minute, and a free account.
Scan your site