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.
“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)Lovable itself is a legitimate, capable platform. The risk isn't the tool. It's shipping AI-generated code without review. The apps it produces can contain serious issues (exposed keys, disabled row-level security) that stay invisible until real users arrive. That's what a security scan checks for.
Two complementary ways: run Lovable's built-in Basic and Deep scans inside the editor (both free), then get an independent static scan of the actual source code. For the second, connect your Lovable project to GitHub (the GitHub icon next to Publish), then point Ascertify at the repository. The free preview shows how many critical findings exist before you pay anything.
Yes, and you should use it. Lovable's Basic scan runs on every publish and its Deep scan is free on demand. Ascertify is different in three ways: it's independent of the platform that wrote the code, its findings come from deterministic tools rather than an AI review (so they're reproducible and pinned to a file and line), and it checks things Lovable's scanners don't, like hallucinated dependencies, whether the data layer was actually built, and whether anyone else could take the project over.
Missing or misconfigured row-level security (RLS) on Supabase tables. RLS is what stops one logged-in user from reading another user's data, and new tables often ship with it disabled. The app works perfectly in testing because you're the only user. The problem only surfaces with real traffic.
No, never. Your code is pulled read-only into an isolated sandbox, read as text, and deleted when the scan completes. We never execute it, install its dependencies, or build it. The report keeps only the findings and the snippets that prove them.
We're a static scan, not a penetration test. We don't probe your live app, test login flows at runtime, or verify how your RLS policies behave with real requests. We tell you exactly what we checked and what we didn't, in every report, because a clean result on a hidden checklist is worthless.
Usually, yes. Each finding includes a plain-English explanation and a recommended first step written so you can paste it into Lovable's agent chat. Review each change it makes, then confirm the issue is resolved.
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