Short answer: Bolt.new is safe to build with, but that does not mean your Bolt app is safe. Those are two different questions. Bolt is a real tool on solid infrastructure, and its own systems are not where things go wrong. What goes wrong is the app Bolt generates for you, because it ships fast and working but not locked. Bolt is very good at building the feature and routinely skips the settings that keep your data and your keys private.
This is not unique to Bolt. It is true of every AI builder that writes your frontend and provisions a database for you. But Bolt's speed-first output makes two of the three gaps especially common, so it is a clear place to see the pattern. Here is what is actually true.
What Bolt.new does well
Credit where it is due. Bolt ships genuinely fast, runs on Supabase and modern hosting, and the Supabase anon key it puts in your browser is supposed to be public and is not itself a vulnerability. If you do the three things below, a Bolt app can be perfectly safe. The problem is only that Bolt does not do them for you.
Scan your own app for issues like these
Paste your live URL. We check what your app serves publicly for exposed keys and misconfigurations. No account, no install.
The three gaps that make a Bolt app unsafe
Every serious exposure we find in Bolt apps comes down to one of three settings the generator leaves off. They are the most boring, most skippable steps in shipping an app, which is exactly why they get skipped.
| The gap | What it means | What a stranger can do |
|---|---|---|
| Exposed secret keys | A real secret (Stripe sk_live, OpenAI sk-, or the Supabase service_role key) got written into the frontend bundle, not just the public one. | Copy the key out of your JavaScript within hours of launch and use it to charge cards, drain your API credits, or bypass every database rule. |
| Missing Row Level Security | Bolt created your Supabase tables with no rule saying who can read which rows, so the public anon key can read all of them. | Grab the public key from your app and run a read on your users or orders table with no login at all. |
| Broken access control | A private page or API endpoint renders to anyone because the only check is the login screen, not the route itself. | Type /dashboard or hit /api/users in a logged-out tab and see the private view or the raw data. |
The exposed-key problem is the one Bolt is most notorious for, because its fast frontend output tends to inline credentials. The access-control gap is the one most people do not know to check, and it is the most common serious issue we find across AI-built apps. We wrote up the data in our study of 2,736 live apps.
The pattern is documented, not hypothetical
The Supabase side of this has a name: CVE-2025-48757, the RLS misconfiguration that exposed 170+ AI-built apps across 303 endpoints, letting anyone read emails, payment status, API keys, and credentials using the public anon key. Bolt apps sit squarely in that pattern, because Bolt creates tables without RLS by default. On the key-leak side, the failure mode is even simpler: one exposed provider key found by a scraper can produce a four-figure bill overnight. Neither of these is a Bolt platform bug. Both are the generated app shipping without a setting the owner assumed was handled.
What our own scans show
We ran the same anonymous, read-only check across a broad set of live AI-built apps to see how common this really is. Of 2,736 apps, 124 (about 1 in 22) served private surface to a logged-out visitor: 89 had an unprotected dashboard or account page, 25 had an API returning data with no token, and 10 had an openly readable database. The full breakdown is in the unprotected-dashboard study, and the database-specific version is in how many AI apps leave their database open.
How to check your own Bolt app
You do not have to guess. Paste your app's URL into Prbl. It does what an outside visitor's browser can already do: looks for a secret key in your bundle, checks whether your Supabase tables answer the public key, and requests your private routes and API endpoints with no session. It takes about 30 seconds, needs no account for the scan, and tells you exactly which of the three gaps your app has, if any.
If it finds something: the fix
- Get secrets out of the frontend. Move every real key into environment variables loaded server-side, and rotate any key that already shipped. The public anon key can stay; a
service_roleorsk_livecannot. - Turn on Row Level Security for every table with an
auth.uid()policy, then work through the Supabase RLS checklist and confirm an anonymous read returns nothing. - Add a real auth check to every private route and endpoint, not just the login screen. This is broken access control, the gap the login page hides.
Frequently asked questions
Is Bolt.new safe to use?
Yes. Bolt.new is a legitimate tool and its own infrastructure is not the issue. The risk is in the app it generates: it builds a working frontend fast, but it routinely leaves keys in the browser bundle and ships Supabase tables with no Row Level Security. So Bolt is safe to build with, but whether your specific app is safe depends on three settings you have to confirm yourself. Most people never check them.
Why does Bolt.new leak API keys?
Bolt generates frontend code quickly, and in the process it often writes API keys and provider credentials directly into source files instead of environment variables. Anything in that frontend bundle is visible to anyone who opens DevTools. Scrapers find exposed keys within hours of deployment, and one leaked paid key (Stripe, OpenAI, a cloud provider) can turn into a four-figure bill overnight. The Supabase anon key in the bundle is fine by design; a service role or provider secret is not.
Does Bolt.new turn on Row Level Security?
No. Bolt.new creates Supabase tables without Row Level Security policies by default. Without RLS, anyone holding the public anon key, which ships to every visitor, can run a read on your tables and pull all the rows: full user lists, orders, submissions. The app works perfectly in testing because the gap only appears when someone queries the database directly, which never happens in normal use and always happens once someone looks.
How do I check if my Bolt.new app is exposed?
Paste your app's URL into Prbl. It runs the same anonymous, read-only checks a stranger's browser could: whether a secret key is sitting in your bundle, whether your Supabase tables answer the public key with no login, and whether your private routes and API endpoints render to a logged-out visitor. It takes about 30 seconds, needs no account for the scan, and tells you exactly which gaps your app has.
How do I secure a Bolt.new app?
Three fixes: enable Row Level Security on every Supabase table and enforce auth.uid() in every policy so each user reads only their own rows; move every secret key out of the frontend into environment variables loaded on the server, and rotate any key that was already shipped; and add a real auth check to every private route and API endpoint, not just the login screen. Prbl gives you the exact step for each finding on your app.
The honest bottom line
Is Bolt.new safe? The platform, yes. Your app, only if you moved your secrets off the browser, turned on RLS, and put a real check on every private route. Checking takes about 30 seconds. Scan your Bolt app and find out which side of this it is on before a scraper does. If you also build with Lovable, the same three gaps apply, covered in is Lovable safe.