Is Bolt.new secure? What the generated app leaves open

Bolt.new can stand up a working full-stack app in minutes, database and all. That speed is the point — and it's also why the security questions get skipped. "Is Bolt.new secure?" is really asking whether the app it generated for you is, and that's a different question with an answerable checklist.

Bolt itself is a legitimate tool. The risk lives in what it hands you: a generated app whose defaults favour working over locked-down, wired up so fast that nobody paused on who else can reach it.

The Supabase connection is where it leaks

When a Bolt app needs to store data, it commonly wires up Supabase — and that brings the single biggest gap in AI-built apps along with it. The app talks to the database from the browser using a public anon key, safe only if Row Level Security is switched on and its policies actually restrict each user to their own rows.

Because generated schema often isn't created through Supabase's Table Editor, RLS is frequently off — and the public key ends up able to read the whole database. It's the identical trap Lovable apps hit; the full mechanics, including the "RLS on but still public" policy trap, are in is my Supabase database public?

Secrets the generator placed for convenience

A model wiring up an integration drops the key wherever makes the code run. That's fine for a publishable key and dangerous for a secret one. Check nothing private shipped in the bundle, and that no secret hides behind a client-exposed VITE_ prefix — the exposed-key problem in full.

Authorization the UI only pretends to enforce

Generated code loves to guard actions in the frontend, because that's where the button is. Hiding an admin control from non-admins isn't access control — the endpoint is still there to call directly. Every sensitive action needs a matching check on the server.

Audit your Bolt app

The fastest pass is to make the model check its own output, table by table and route by route:

My app was built with Bolt.new. Audit it for the security gaps Bolt-generated apps commonly ship with, and give me the exact fix for each.

1. If it uses Supabase: list every table and whether Row Level Security is enabled. Flag any table that's off — readable/writable by anyone with the public anon key. For tables with RLS on, tell me whether the policy actually restricts rows to the owning user or effectively allows everyone.
2. Secrets: are any API keys, tokens, or private keys committed to the repo or shipped in the client bundle? Which must move to server-side environment variables? Check that no secret uses a client-exposed prefix (VITE_ / NEXT_PUBLIC_).
3. Authorization: is every sensitive action checked on the server, or is any of it enforced only in the UI where a user could bypass it by calling the endpoint directly?
4. Leftover routes: are there any debug, admin, or seed endpoints still reachable in production?

For each finding, give me the file/table, the risk in one sentence, and copy-pasteable code or SQL to fix it.

This is the Bolt-specific cut of a pattern that runs through every AI builder — the cross-cutting version is vibe coding security risks, and the Supabase deep-dive is how to secure a Supabase app.

The part you can check from outside

RLS and secrets live in the code, but the certificate, headers, and cookies live on the public URL — testable in seconds: