Every claim in this table comes from the vendors' own published documentation, linked at the bottom. Where we don't know something, we say so rather than guessing.
| Lovable Basic & Deep Scan | Bolt security agent | Broid | |
|---|---|---|---|
| Price | Free | Free, and doesn't consume your tokens | Free grade; $1 or less per full report |
| When it runs | On demand, in the editor | Automatically, on publish | Any time, on any live URL |
| What it reads | Your source code, schema and dependencies | Your source code before it ships | Only what your live app exposes publicly |
| Reads source code | Yes | Yes | No |
| Tests the live app | No | No | Yes |
| Writes the fix for you | Suggests | Writes and applies | Gives a copy-paste prompt for your builder |
| Works on apps built elsewhere | No | No | Any site, any stack |
| Independent of the code's author | No | No | Yes |
| Public trust artefact | Trust Center at /.well-known/trust.html | Score shown to you only | Badge + public verification page |
It would be easy to write this page as though the built-in tools were theatre. They aren't, and pretending otherwise would be the kind of unverifiable claim we refuse to make about anything else.
If you only ever do one thing, running the built-in scan is a better use of five minutes than reading the rest of this page.
A code scan reasons about what your app should do. It reads policies, endpoints and dependencies as written. What it does not do is stand outside your deployed app with the same public key any visitor has and ask the database for your users table.
That distinction matters because the gap between "the policy exists" and "the policy holds on the live site" is where the real incidents live. Environment variables differ between preview and production. A policy gets disabled during debugging at 1am and never re-enabled. A table is added after the last scan. A custom domain serves without HSTS. None of these are code defects, so a code scanner has no reason to report them — and every one of them is visible from outside in seconds.
This is also why the two approaches shouldn't be ranked. A code scan can see a vulnerable function that is never reachable from the internet. An external scan can see a readable table that the code says is protected. Each one's blind spot is the other's specialism.
This is the part that isn't about features, and it isn't a slight against any platform. It's the reason external audit exists as a profession at all.
The evidence, on the record:
The two-hour fix and the public post-mortem are a better response than most companies manage, and we'd say so on any page. But the finding stands: a platform's own security tooling did not detect a flaw in that platform for over two months. That is not carelessness, it is structure. You cannot see the assumption you are making, because you are making it.
Every platform ships bugs. The question a built-in scanner can never answer is "what did the system that wrote this code fail to notice about the code it wrote?"
Lovable now publishes a Trust Center on externally published apps at /.well-known/trust.html, showing verifiable security facts observed about the live app. Your app's code cannot edit the results, and Lovable is explicit that it is informational, not a certification. It is a genuinely good feature and more than most platforms offer.
Here is the useful thing an outsider can do with it, which nobody inside the platform can: read what it reports and independently measure the same app. "The Trust Center reports X. We measured Y from outside, on this date." When those agree, you have something much stronger than either alone — two independent sources on the same claim. When they disagree, that discrepancy is the single most valuable security finding you will get that day.
Self-reporting plus independent verification is how every audited claim in finance and manufacturing works. It isn't a criticism of self-reporting; it's the other half of it.
Run both, in this order: your platform's built-in scan for the code, then an external scan for the live URL. The second one is free.
Scan my app free →A comparison page that finds no fault with its author isn't a comparison, it's an advert. So, plainly:
| Situation | Do this |
|---|---|
| Building on Lovable or Bolt, pre-launch | Run the built-in scan and fix what it finds. It's free and it reads your code. |
| About to launch to real users | Both. The built-in scan for the code, an external scan for the live URL. They catch different things. |
| Handling money, health data or anything regulated | Both, then a human penetration test. No automated tool of any kind is sufficient here, ours included. |
| Built somewhere else, or by hand | External scan — there is no built-in one to run. |
| You're an agency, and the client asks "is it safe?" | External, because it's the only one you can show a client. A platform grading its own output isn't evidence they can act on. |
| You want proof for a customer or an enterprise buyer | Independent verification. That's the entire point of the word. |
Yes. Both the Basic Scan (RLS policy linting, schema review, dependency audit) and the Deep Scan (access-control review, backend endpoint protection, code-level vulnerabilities) are free in the editor. Conversational security reviews — prompting "review my app's security" — consume credits. Lovable's own documentation notes that these tools "cannot guarantee complete security."
Yes. Since 30 July 2026 Bolt's security agent runs on publish. It covers access control, authentication, business logic, database policies, information disclosure, secrets, and injection/XSS — and it writes and applies fixes rather than only reporting them. It's free and doesn't consume your tokens. You get an overview of the fixes and a risk-mitigation score; there's no public certificate.
Because the two tools look at different things. A code scan reads what your app is written to do; an external scan tests what your deployed app actually exposes right now. The common failures — a policy disabled during debugging, a table added after the last scan, production environment variables that differ from preview — are invisible to a code scan by design, and obvious from outside.
An automatic page at /.well-known/trust.html on externally published Lovable apps, showing verifiable security facts observed about the live app. Your app's code can't edit the results. Lovable states it is informational, not a certification. It's a real improvement on self-declared trust seals — and it becomes stronger still when an independent scan measures the same app and agrees.
Not equivalent to Lovable's or Bolt's at the time of writing. If you build with either, an external scan of the deployed URL is currently the practical option — along with the manual checks we publish free.
Fair challenge, and the answer is that you shouldn't take our word either. That's why we publish exactly what the scan does — it uses only your app's own public key, counts rows without reading them, makes no writes, and stores no source code — so you can verify every request from your own server logs. We also publish the manual version of every check so you can do it yourself without involving us at all.
Only time. They don't conflict, and neither is a substitute for the other. If you have five minutes, run the platform's. If you have ten, run both. If you're handling money, budget for a human test as well.
Paste your URL and get an A–F grade in seconds, including a live database-exposure test using only your app's own public key.
Scan my app freeBroid is independent — we don't build apps, so we have no reason to tell you yours is fine.