Is Bolt Safe? Security Risks and the Checklist Before You Ship

You built your app on Bolt, it works, and now it's getting real — real users, maybe real payments. Which is exactly when the worry shows up: is Bolt safe to ship a real app on, or did the AI leave your users' data exposed without telling you?

It's the right question to ask before launch, not after. Bolt is a capable AI builder, and the apps it produces really do work. But "works in the preview" and "safe in front of strangers" are two different things, and the distance between them is where data leaks happen.

The reassuring part: Bolt the builder isn't the problem. The risk lives in the backend it wires up for you — usually Supabase — and in a few specific settings the AI doesn't reliably get right. This post shows you exactly where those gaps tend to be and gives you a checklist to run before you ship.

⚡ TL;DR

• Bolt is safe to build on. The risk is the backend it generates — typically Supabase — and whether its tables have proper Row Level Security (RLS = a per-user filter on every database query).
• The most common Bolt gap is missing or "allow everyone" RLS. This is the same pattern behind CVE-2025-48757, which found about one in ten scanned AI-built apps leaking real user data this way.
• Your Supabase anon key being public is not a bug — it's meant to ship in the browser. The fix is RLS policies, not rotating the key.

Is Bolt safe? The short answer

Yes, with one caveat that does the real work.

Bolt is a legitimate platform, and the code it generates isn't malicious or broken. When founders ask "is Bolt safe," they're usually imagining the wrong risk. The danger isn't that Bolt does something sneaky behind your back. It's that Bolt, like every AI builder, optimizes for making the feature work in the preview — not for controlling who can reach your data once it's deployed.

Those are different jobs. An app can look finished, work flawlessly in the demo, and still leave its database open to anyone. The gap is invisible right up until someone goes looking.

So the honest answer: Bolt is safe to build on, but the app it hands you isn't automatically safe to ship. The difference comes down to a handful of settings the AI doesn't always configure correctly — and you can check and fix every one.

The real risks when you build with Bolt

Bolt commonly uses Supabase as its backend. Supabase is excellent and is the default across the vibe-coding world, but it ships with a permission model your AI has to set up correctly. Here's where it tends to slip.

Missing or permissive RLS (the big one)

This is the central risk for a Bolt app, so it gets the most attention here.

Supabase apps talk to the database directly from the browser. There's usually no backend server in the middle asking "is this person allowed to see this?" The database itself is the gatekeeper, and the feature that enforces the rules is RLS (Row Level Security) — an automatic WHERE clause the database adds to every query, deciding which rows each user can see.

When RLS is turned off, or when a policy is set to USING (true) (which means "match every row" — effectively no protection), any visitor can pull the entire table. Everyone's data, not just their own.

Why does this happen on Bolt? Because a table with RLS switched off works perfectly in the preview. You can read and write rows, the app looks done, nothing complains. The hole only appears when an outsider queries your public API directly. We go deep on this in Supabase RLS explained.

This pattern isn't hypothetical. The first published CVE for this category, CVE-2025-48757, came from scanning AI-built apps and finding 170 of 1,645 (about 10.3%) leaking user data through missing or USING (true) RLS. That study focused on Lovable apps, but the same root cause recurs on Bolt, v0, Cursor, and Replit, because they all share the browser-to-database architecture. There's no separate documented Bolt incident — the risk is the shared default, and it's the one to check first.

The USING(true) trap

It's worth calling this out on its own, because it fools people. A Bolt app can have RLS enabled on every table and still leak everything, if the policies are written as USING (true). That setting looks protected in the dashboard — the toggle is green — but it passes every row to every requester. Turning RLS on is necessary but not sufficient; the policy underneath has to actually restrict rows. See the USING(true) trap.

Exposed secret keys

Bolt apps connect to other services — Stripe, OpenAI, email providers. The risk is a secret key getting baked into the frontend that ships to the browser. Keep the distinction clear:

• A Supabase anon key and a Stripe publishable key (pk_live_...) are meant to be public. Not emergencies.
• A Supabase service_role key, a Stripe secret key (sk_live_...), or an OpenAI key in client code is an emergency. The service_role key especially — it bypasses RLS entirely, so anyone who finds it owns your whole database.

If your Bolt app calls a paid API directly from the browser, the secret may be sitting in your JavaScript bundle. See service_role vs anon key.

Open storage buckets

If your app lets users upload files, Bolt likely created a Supabase storage bucket. Buckets have their own access rules, separate from your tables. A public bucket means its files can be listed and downloaded by anyone with the URL pattern, even when your tables are locked down. It's an easy blind spot because storage feels like a different system from the database. See Supabase storage bucket security.

Missing security headers and CSRF protection

AI builders rarely set security response headers or CSRF (Cross-Site Request Forgery) protection. A December 2025 study of 15 AI-built apps found zero implemented CSRF protection and zero set security headers. Bolt apps inherit the same tendency. Lower-severity than an open database, but worth closing before launch.

How to check your Bolt app

You can sanity-check the important things in about ten minutes.

1. Open your Supabase dashboard → Authentication → Policies (or Database → Tables). Every table holding user data should show RLS enabled. A table with real data and "RLS disabled" is your most likely leak.
2. Read the policy, not just the toggle. A table with RLS on but a USING (true) policy looks safe and isn't. Confirm policies use real conditions.
3. Hunt for secret keys in your frontend. In browser dev tools, search your loaded JavaScript for service_role, sk_live, and any AI provider key prefix. None should appear. (An anon key is expected and fine.)
4. Check your storage buckets. In Supabase → Storage, confirm buckets with private files aren't set to public.
5. Test as an anonymous user. Query your public API with only the anon key and see what comes back. If you can read other people's rows, so can anyone.

The pre-ship checklist for Bolt

Run through this before real users touch your app.

• RLS enabled on every table that holds user data — no exceptions.
• Policies use real conditions, like auth.uid() = user_id, never USING (true).
• No secret keys in the frontend: no service_role, no sk_live_..., no raw AI provider keys in client code.
• Storage buckets locked down: private files in private buckets, with access policies.
• Tested as a stranger: you've queried your live endpoints anonymously and confirmed you can't read other people's data.
• Security headers and CSRF protection added where your stack supports them.

A useful move: paste a prompt back into Bolt like "Enable RLS on every table that stores user data and add policies so each user can only read and write rows where user_id equals their auth.uid(). Do not use USING(true). Make sure no secret keys are exposed in client code."

FAQ

Is Bolt secure enough for a production app with paying users?

Yes, as long as you configure the backend correctly. Bolt can power a production app, but you're responsible for confirming RLS is enabled with real policies, no secret keys ship in the browser, and storage buckets are locked down. The platform doesn't guarantee these by default — you verify them before launch.

Is my Bolt app leaking data right now?

Possibly, if it has tables without proper RLS. The CVE-2025-48757 study found about one in ten AI-built apps leaking this way, and Bolt apps share the same architecture. The only way to know for sure is to check your table policies and test your live endpoints as an anonymous user.

Do I need to rotate my Supabase anon key in a Bolt app?

No. The anon key is public by design — it's meant to live in your frontend, and Supabase built its permission model around that. Rotating it changes nothing. The key you must never expose is the service_role key.

The bottom line

Bolt is safe to build on, and the platform isn't doing anything wrong. The risk is the one every AI builder carries: it optimizes for "it works," not "it's locked down," and the gaps it leaves — missing RLS, USING (true) policies, exposed secret keys, open buckets — are invisible until someone goes looking. An attacker can find an unprotected table in minutes by reading your network traffic. The job is to find it first, and to keep checking, because Bolt ships new code (and potentially new gaps) every time you add a feature.