Search "Lovable vs Bolt vs v0" and you get a dozen pages comparing generation speed, framework support, pricing and design quality. Almost none of them mention security, and the few that do reduce it to "has a scanner: yes/no."
That checkbox stopped being useful some time in 2026. All five have scanners now. What follows is the comparison nobody publishes: what each one actually checks, when, at what price — and underneath it, the architectural difference that determines what happens when the scanner misses something.
| Lovable | Bolt | v0 (Vercel) | Replit | Cursor | |
|---|---|---|---|---|---|
| Built-in scanning | Yes | Yes | Yes | Yes | Teams/Enterprise only |
| Since | Not published | Oct 2025 | Aug 2025 | May 2025 | Apr 2026 |
| When it runs | On demand, in editor | On publish + on-demand whole-project audit | During generation and before deploy | Automatically, mid-task since 7 Aug 2026 | On every pull request |
| Applies fixes | Flags | Yes, most of them | Blocks deploys; auto-fix not stated | Agent fixes findings | Comments inline; auto-fix not stated |
| Detection method | Not published | Not published | Not published | Semgrep — deterministic rules | LLM agents + optional SAST/SCA via MCP |
| Cost | Free (conversational reviews use credits) | Free, doesn't consume tokens | Not published | Free (Semgrep Community Edition) | Charged to the team usage pool |
| Public trust artefact | /.well-known/trust.html | Score to you only | None found | None found | N/A |
| Hosts your app | Yes | Yes | Yes | Yes | No — it's an IDE |
The most interesting cell in that table is Replit's detection method. Replit runs Semgrep — around 200 curated deterministic rules for Python, JavaScript and TypeScript — and has published research arguing that LLM-only security scanning is nondeterministic, that "identical vulnerabilities receive different classifications based on minor syntactic changes." Lovable and Bolt do not publish how their scanners detect issues. Whether you weigh that as an advantage depends on your view of recall versus repeatability, but it is a real technical distinction and nobody else writes it down.
The second is v0's number. Vercel reported that in a 30-day window, v0 blocked over 17,000 deployments for exposed secrets alone. Take it as vendor-published and a year old — but the order of magnitude tells you how routinely AI-generated code puts keys where they don't belong.
Scanning is a detection layer bolted onto an architecture. The architecture decides what a miss costs.
| Browser talks to DB directly? | Server tier by default? | Is RLS the only protection? | |
|---|---|---|---|
| Lovable | Yes | No app server | Yes, for normal data access |
| Bolt | Probably — not confirmed | Server functions exist, not the default path | Likely, for direct table access |
| v0 | No, by default | Yes — RSC, Server Actions, API routes | No — server code is a second layer |
| Replit | Depends on what the agent builds | Depends | Depends |
| Cursor | Your choice | Your choice | Your choice |
An independent technical teardown of Lovable's architecture describes it plainly: "the browser communicates directly to the Supabase primitives through a single shared client," and Supabase "exposes its database via PostgREST" — a web server that turns PostgreSQL into a REST API. The stack is React, Vite and TypeScript in the browser; secrets live in Supabase Edge Functions. There is no traditional application server between your user and your data.
Lovable's own documentation states the consequence without stating the cause: "Before going live, make sure every table has Row Level Security policies," and "missing RLS policies are the most common way app data gets exposed."
Supabase's documentation contains the conditional that is the entire security model: your publishable key "is safe to expose with RLS enabled, because row access permission is checked against your access policies and the user's JWT."
v0's documentation defaults to the Next.js App Router — "Next.js provides the most reliable results" — using React Server Components, Server Actions and API routes. Environment variables are server-only unless explicitly prefixed NEXT_PUBLIC_.
In that shape, a missing database policy is mitigated by the fact that the browser can't reach the database at all. It can only call the server functions your app chooses to expose. The failure mode is narrower — you can still write a broken server action, but you have to write it.
Honest caveat: this is a default, not a guarantee. v0 supports Supabase, and Supabase's client SDK can be used from the browser. If you or the AI wire it up that way, you inherit Lovable's failure mode on a Vercel deployment.
Cursor is an IDE. There is no hosting layer, no deploy gate, no runtime, no database provisioning, no platform firewall — and therefore no "runs on publish", because there is no publish. Its Security Review (Teams and Enterprise plans, charged to the team's usage pool) reviews pull requests; it does not gate shipping. The security of an app built with Cursor is determined entirely by the stack the developer chose.
Easy to overlook, and it matters: Vercel applies automated DDoS mitigation on all plans regardless of tier, with HTTPS and TLS by default. The configurable WAF — custom rules, IP blocking, managed rulesets — is a paid add-on. Vercel also ships automatic secret scanning that detects and revokes Vercel and v0 credentials leaked to public GitHub, gists and npm, for all users.
These are real protections that no application-level scan replaces, and they're a genuine argument for the hosted platforms over rolling your own.
Read the critical breakdown again. 172 live applications where a stranger with no account could delete your data. That is not a theoretical risk model — it is the browser-direct architecture with a missing policy, counted.
Caveats, because they matter. The study was published by Symbiotic Security, which sells security products. The sample is discoverable public apps with Supabase backends, which biases toward exactly the architecture under discussion. And no per-platform breakdown was published — so nobody, including us, can honestly say "X% of Lovable apps" from this data.
Veracode's GenAI code security research tested 100+ large language models on security-sensitive coding tasks. The 2025 result: 45% of code samples failed security tests, with Java at 72% failure and cross-site scripting defended correctly in only 14% of relevant samples.
The 2026 update is the more important finding: across 150+ models tracked since 2023, the pass rate sits at 55% — statistically unchanged, described as "stubbornly stuck" and "virtually identical to where they stood two years ago." Syntactic correctness is above 95%. Log injection passes 13% of the time; XSS 15%.
The implication for anyone choosing a builder: waiting for the models to get safer is not a strategy. Two years of frontier model progress moved code correctness a long way and code security almost nowhere.
A December 2025 study built 15 applications — three each from five tools, from pre-defined identical prompts — and found 69 vulnerabilities. Critical findings by tool: Claude Code 4, Devin 1, OpenAI Codex 1, Cursor 0, Replit 0.
Note carefully that the five tools were Claude Code, Codex, Cursor, Replit and Devin — not Lovable, Bolt or v0, despite several write-ups implying otherwise. Its most useful qualitative finding: the agents were "very prone to business logic vulnerabilities" in API authorisation and e-commerce flows, while the researchers "didn't encounter a single exploitable SQLi or XSS vulnerability." The classic injection bugs are largely solved; authorisation logic is not.
Whichever platform you built on, the check that matters is the same: can a stranger read your database right now? Broid tests it from outside in seconds, free.
Scan my app free →The honest answer is that the question is slightly wrong, and here is the more useful version of it:
| If you care about… | The answer |
|---|---|
| Narrowest default failure mode | v0. A server tier by default means the browser cannot reach your database, so one missed policy is not immediately catastrophic. |
| Most automatic remediation | Bolt. It writes and applies most fixes itself, which matters most for non-technical builders — the people least able to act on a findings list. |
| Most repeatable detection | Replit. Deterministic Semgrep rules running automatically mid-task, plus published research on why that matters. |
| Public evidence you can show a customer | Lovable. It's the only one publishing a per-app trust artefact your app's code cannot edit. |
| Full control | Cursor — which also means full responsibility. Nothing is enforced for you. |
| Not becoming one of the 172 | Any of them, if you verify RLS on every table before launch. That's the check that dominates all the others. |
Worth knowing when you pick an AI coding tool, because this is a new category of risk that didn't exist three years ago.
The pattern across all of these: they were found by outsiders, not by the platforms' own tooling. That's not a slight on any vendor — a two-hour fix and a public post-mortem is a better response than most companies manage. It's a structural fact about self-audit, and it's the reason an independent check is worth ten minutes even when the built-in scan says green.
select tablename, rowsecurity from pg_tables where schemaname = 'public'; — anything showing false is open to the public key. This one check dominates every other item on this page.By default architecture, v0 — it puts a Next.js server tier between the browser and the database, so a missing database policy isn't immediately catastrophic. But the question matters less than it sounds: in a scan of 1,072 live apps across seven platforms, 98% had at least one flaw. The variable that dominates platform choice is whether you verify Row Level Security on every table before you launch.
Yes, and so do Replit and Cursor. v0 has applied security checks during generation and before deploy since August 2025; Replit added Semgrep pre-deployment scanning in May 2025 and made it automatic on 7 August 2026; Bolt has checked on publish since October 2025 and added a whole-project audit with auto-fix in mid-2026; Cursor shipped Security Review in April 2026 for Teams and Enterprise plans. Scanning is table stakes now.
Because a Lovable app has no application server — the browser queries Supabase directly through PostgREST using a key that is public by design. RLS is the only thing deciding what that key may do. A table without a policy has no access control whatsoever, rather than one missing layer among several. On a Next.js app with server actions, the browser can't reach the database at all, so the same mistake has a much smaller blast radius.
In the largest published scan — 1,072 live apps across seven platforms, all with Supabase backends — 98% had at least one flaw, 16% had a critical one, and the average was 5.9 vulnerabilities per site. It was published by a security vendor and the sample skews toward publicly discoverable apps, so treat it as directional. Separately, Veracode's testing found large language models produce insecure code in roughly 45% of security-sensitive tasks, a rate essentially unchanged over two years.
Not comparable in that way. Cursor is an editor, not a hosting platform — it has no deploy gate, so the security of what you ship is entirely down to your stack. Notably, in the one study using identical prompts across five agentic tools, Cursor and Replit produced zero critical vulnerabilities while Claude Code produced four. Cursor the product has had its own vulnerabilities, including CVE-2025-54136 and a rules-file attack it declined to patch.
Not automatically — a hand-built app by an inexperienced developer can be worse. What AI builders change is the failure distribution: they produce syntactically correct code with systematically weak authorisation, and they default to architectures where one configuration mistake is critical rather than incremental. Veracode's finding that model security performance hasn't improved in two years while syntactic correctness exceeds 95% is exactly that shape.
For basic checks, largely yes — and that's a good outcome for everyone. What a built-in scanner can't do is test the deployed app as a stranger meets it, or be independent of the system that generated the code. Every incident listed on this page was found by an outsider rather than by the platform's own tooling, which is the argument in one line.
Paste your URL and get an A–F grade in seconds, including the live database-exposure test, whichever platform you built on.
Scan my app freeBroid is independent — we don't build apps, so we have no reason to tell you yours is fine.