Lovable writes code fast, and fast code ships with fast mistakes: API keys in the browser, database tables anyone can read, packages that don't exist. Ascertify reads your app's actual code and shows you what's exposed, in plain English, pinned to the exact file and line. Before your users find out for you.
Connect your GitHub repo (Lovable syncs to it in two clicks). Read-only access. We never run your code, and it's deleted after the scan.
Your secret database admin key is sitting in code that ships to the browser. It bypasses every access rule you have. Anyone who opens your site can read or change all of your data.
Lovable apps run on Supabase, which means the same handful of mistakes account for most of the real risk. Every one of these is invisible in the app itself and obvious in the code.
We measured how often these show up across public Lovable apps. Read the September 2026 report.
“can other users see my users' data?”
Supabase tables ship with RLS off, and the AI doesn't always turn it back on. Your app works perfectly in testing because you're the only user. The moment real users arrive, they may be able to read each other's records.
“can someone steal my OpenAI / Stripe / database keys?”
Keys pasted into client-side code ship to every visitor's browser. Anyone who opens dev tools can copy them, run up your bill, or reach your data.
“what's the worst-case version of an exposed key?”
This one. The service-role key bypasses every access rule you have. In frontend code, it's equivalent to publishing your database password. Rare, and the single most urgent thing we ever find.
“did the AI invent a package?”
AI tools sometimes hallucinate plausible-sounding package names. At best your app can't be installed cleanly. At worst, someone publishes malware under that exact name, waiting.
“could anyone, including future me, rebuild this?”
When there are no migration files, your database's structure exists only in the live system. A new developer (or you, after a bad day) can't recreate it.
Lovable ships two free scanners: a Basic scan on every publish and an on-demand Deep scan. They're worth using. So why pay for a second opinion? Because they answer a different question than we do.
| lovable's built-in scans | ascertify | |
|---|---|---|
| RLS misconfiguration | Checked | Checked, pinned to the migration file and line |
| Exposed secrets / API keys | Checked | Checked, including full git history |
| Dependency CVEs | Checked | Checked |
| Dependencies that don't exist (AI-hallucinated) | Not covered | Covered |
| Whether the data layer was actually built | Not covered | Covered |
| Setup completeness: could a new dev take over | Not covered | Covered |
| How the code was built over time (git history) | Not covered | Covered |
| Discovery method | AI agent reviews the code | Deterministic tools find; AI only explains |
| Who's checking | The platform that wrote the code | An independent third party |
| What you get | Findings inside the Lovable editor | A forwardable report with file-and-line evidence, plus what we checked and didn't |
The short version: Lovable's scan asks “is this secure enough to publish?” from inside the tool that built it. We ask that too, plus “what actually got built, and could you keep building without it?” From outside, with evidence you can hand to anyone.
In Lovable, click the GitHub icon next to Publish and connect. Then point Ascertify at the repo. Read-only, revocable anytime.
Deterministic checks, no guesswork. Every finding shows the exact file, line, and snippet that triggered it.
Each finding comes with a recommended first step, written so you can hand it to Lovable's agent.
You built this in a weekend for the price of a subscription. Knowing it won't leak your users' data costs $49, once.
Free preview
A count of the critical findings in your code. Enough to know whether there's a problem worth raising, before you pay for the detail.
Run free previewEvery finding with file-and-line proof, the exact code, a plain-English explanation, a recommended first step, and a PDF you can forward to your developer.
Get full report ($49)The one thing worth understanding in depth (what correct RLS actually looks like), plus the pre-launch checklist to run before you publish.
Row-Level Security is the most important thing to get right, and also the most commonly broken. RLS controls which rows in your database each user can access. Without it, any user could read, change, or delete anyone else's data.
A big mistake is only testing whether users can read data. You need to check all four operations, on every table:
| Operation | What to verify |
|---|---|
| SELECT | Unauthorized requests return a 401 or only the user's own rows |
| INSERT | Users can't add rows owned by someone else |
| UPDATE | Users can't modify records that aren't theirs |
| DELETE | Users can't delete records that aren't theirs |
Some RLS policies look correct but don't actually protect you. A common trap is a policy missing a WITH CHECK clause. Without it, a user could insert a row and assign it to someone else, or even change their own user ID or role. A secure policy must explicitly scope access to the caller's identity. If a policy doesn't tie the operation back to who's actually logged in, it isn't doing its job.
The free preview takes a few minutes and tells you whether there's anything worth worrying about. Start there.
Scan my Lovable app, free previewRead-only access · code deleted after the scan · one-time payment, no subscription