Bolt, Lovable, v0, Cursor: what actually changes on the security side
We're not going to hand you a ranking with made-up percentages — "X% of Bolt apps are vulnerable" doesn't exist without a rigorous statistical study, and we don't have one. What we can compare honestly is how each tool architects the backend by default — because that's what determines where your risk concentrates, not the tool's brand.
Bolt.new and Lovable: the turnkey backend
Both push hard toward a one-click Supabase integration for the database, auth, and storage. That's what makes them fast: in a few prompts you get a full CRUD, a users table, and often a Stripe payment flow wired up on top. The trade-off is that the same risk profile shows up on every project generated this way: a public anon key by design, and real security resting entirely on well-written RLS policies — a step the initial prompt doesn't always cover, and that has to be checked explicitly afterward.
Concretely: on a Bolt or Lovable project with Supabase, the three things to check first are always the same — RLS enabled on every table, policies that aren't USING (true) by accident, and no service_role or sk_live_ key leaked client-side.
v0: more frontend-first, risk depends on what you wire up behind it
v0 has historically been focused on generating components and pages — UI-first. It doesn't push you toward a default backend the way Bolt or Lovable does. That means the "exposed backend" risk isn't structural to the tool: it shows up the moment you connect a database, an API, or a payment service to the generated component. The vigilance shifts from "is the scaffold safe by default" to "does what I added afterward follow the same rules" — secret key never client-side, RLS if you add Supabase yourself, and so on.
Cursor: no platform, so no default architecture
Cursor is an AI-assisted code editor, not a deployment platform with preconfigured integrations. There's no "default Cursor backend" — the outcome depends entirely on what you ask it and the existing code in your project. That's both safer (no pattern repeated at scale) and risky in a different way: an assistant that answers very quickly to "add authentication" can generate working code without flagging that the key it just used shouldn't be in a client file — because nothing in the prompt explicitly asked for a security review.
The real common denominator
Regardless of the tool: an LLM optimizes for "make the requested feature work", not "minimize the attack surface". A key that works on both sides (client and server) solves the immediate problem faster than a clean architecture with a dedicated API route — so that's often what comes out in the first pass, whichever tool wrote it.
What matters, regardless of the tool
- Check the client/server split of every key and secret, not just "does it work".
- If Supabase (or equivalent) is wired up, audit RLS explicitly — never assume the scaffold got it right.
- Re-test after every significant prompting session, not just at the end of the project — a regression can be reintroduced by a later prompt touching the same file.
Whichever tool you used to build your app, a Vetora scan checks these points from the outside, the way an attacker would.