Is Bolt safe? What 1,123 live Bolt apps showed

You built something on Bolt, pressed Publish, and now it lives at an address ending in bolt.host. Before you send that link to real customers you typed "is bolt safe" into a search box, and what came back was a list of five vulnerabilities said to be in almost every Bolt app, with a scanner for sale at the bottom.

Here is what those lists get wrong: they rank every risk the same, and on live Bolt apps most of them barely appear. Source maps, open cross-origin headers and unprotected API routes sit on those lists as equals of leaked keys and open tables. In our data the first three turned up on 13, 1 and 4 apps out of more than a thousand. The other two are where the findings were.

Between 12 and 14 August 2026 we ran the same nine external checks anyone can run free on our homepage over 30,998 live apps, and 1,123 of them were published on Bolt's own hosting. This is what came back for those, and where our view stops.

Is Bolt safe?

On everything Bolt itself decides, yes. Its hosting came back as clean as Lovable's, and everything that lowered a grade sat inside an app its owner had built.

Think of a Bolt app as a shop. Bolt puts up the building: the address, the certificate, the hosting. You fill the shop window, which is every page, image and script your app hands to a visitor, and anyone walking past can read whatever is in it. Behind the shop is the stockroom, your database, with its own door and its own lock. "Is Bolt safe" is really three questions, one about each.

1. The building. Does Bolt publish your app properly: a valid certificate, a domain that will not lapse, nothing stray left at a public address. This is Bolt's job.
2. The window. What a visitor's browser downloads. A key left in it can be read by anyone who looks, however it was put there.
3. The stockroom. Whether your database answers a stranger who walks round the back and asks. That depends on a lock you set, table by table.

Our checks read all three from outside. None of them reads the code Bolt's agent wrote the way you would read it in the editor, and this post does not guess at it.

What we found in 1,123 Bolt apps

Nine checks, run from outside, with no login and no access to anyone's account. Where a database answered, we asked how many rows it would hand over and stopped there; we never read one. No app is named here or anywhere else we publish. Every share below is of the apps that check answered on, because a check that could not finish is unknown rather than passed, and that rule is why the denominators move. The method and the data are in the report.

The grades: 1,051 A, 33 B, 24 C, 15 D and no F at all.

That first row is decided by whoever serves your pages, which on yourapp.bolt.host is Bolt, so 1,121 apps got the same answer. Headers are worth having and they are not what a D is made of. Leave that row out and 1,008 of the 1,123 Bolt apps had nothing else at all. The other 115 are what the rest of this post is about.

What Bolt gets right

The checks Bolt decides came back almost empty, and on the one build setting we measure it matched Lovable.

Source maps. 13 of 1,123 Bolt apps publish the original files behind the app, comments and all. That is a little over one in a hundred, about the same rate as Lovable's 225 of 18,553, and a map gives away more than people expect.

Cross-origin headers. One app out of 1,120 told every website in the world that it may call its API. That is the finding most likely to let another site act as your user, and on Bolt it appeared once.

The building itself. The certificate was valid on all 1,119 apps where we could read one, no domain out of 1,123 was close to lapsing, and no app served a .env file or a .git/config from a plain address.

None of that needed anything from you, and on some other builders it does.

What the 75 keys were made of

Most of them were fine, and the few that were not are the most expensive thing in this post.

75 of the 1,123 Bolt apps had something key-shaped in the code a visitor downloads. Counted as shapes, that is 7% of Bolt apps "leaking secrets". Counted by what each key can do, it splits like this, with each app counted once under the most serious thing in it:

The 38 Google keys are the reason we classify every key instead of matching a pattern. A Google Maps key in a browser is where it is supposed to be, and the fix is restricting it to your own domain.

The ten OpenAI keys are the opposite case. An OpenAI key is a bearer token: whoever holds it can spend it, from anywhere, and OpenAI offers no setting that ties a key to your site. All ten of those apps graded D, because one critical finding caps the grade whatever else the app got right. What to do about one, in order starts with rotating it today.

Here is the number that makes this the Bolt finding. Bolt apps were under 4 in every 100 apps we scanned, and they carried 10 of the 33 OpenAI keys we found anywhere. Put per app, that is about one Bolt app in 110, against 18 of the 18,554 Lovable apps, about one in a thousand. Ten apps is a small sample, and a handful either way would move that ratio a long way. It would still leave Bolt ahead of every other builder we measured.

Why do Bolt apps leak API keys?

We cannot see from outside how any one of those ten keys got there, and Bolt's own instructions say none of them should have.

Bolt's documentation describes the intended path. Ask the agent to integrate OpenAI and, in the documentation's words, it will "complete the coding and then display a message asking you to add your secret". That secret goes in the Secrets panel, where only a server function can read it. A server function runs on Bolt's side, so the visitor's browser never receives the key. Built that way, the key stays in the stockroom.

The route around it that we can name is the environment variable. Bolt's own introduction to databases says that environment variables keep these values private, and two of the three names it lists, VITE_SUPABASE_URL and VITE_SUPABASE_ANON_KEY, start with VITE_. That prefix belongs to Vite, the build tool, and Vite's documentation says the opposite about it: a VITE_ variable is written into the code the browser downloads, and it should never hold an API key. For those two names that is harmless, because a project address and a publishable key are meant to be public. Copy the same pattern for VITE_OPENAI_API_KEY and the key is sitting in the window.

A key pasted into the chat while you were fixing something else can also end up written straight into a page. Either way the result is the same file. How the prefix works covers which values belong behind it and which never do.

27 of 35: the Bolt databases we could ask

Of the Bolt databases that gave us a usable answer, 27 of 35 handed rows to a request carrying no login at all. That is a count, and the base is too small to print as a percentage.

The denominators matter more here than anywhere else in this post. 266 of the 1,123 Bolt apps named a Supabase project in the code they ship. Only 35 of those answered our request well enough for us to judge. The other 231 could not be judged, which makes them unknown, and we have counted them as neither clean nor exposed.

In 4 of the 27 the table that answered was named the way tables about people are named, such as users or profiles. Those four and the eleven apps with an OpenAI or Anthropic key make up all 15 of the D grades. In the other 23 it was a table we could not name from outside, which may be a product list that was always meant to be public or may be anything else.

Why it lands on the database

Because the stockroom's address is printed in the window, and it has to be.

When a Bolt app reads its data from the page, the page needs the address of the database and a publishable key, so both travel to every visitor. That key being public is correct; it is how your own app gets in. What decides what the key gets back is a per-table setting called row-level security. With it on and a policy written, the public key reads only the rows the policy allows. With it off, it reads the table.

Supabase turns row-level security on by default for tables you create by clicking around in its Table Editor. Tables created by running SQL do not get it, and running SQL is how a builder creates tables for you. Turning it on is also only step one, because the policy an assistant writes to clear a permissions error is often using (true), which permits everybody while the dashboard reports the table as protected. RLS is on and your table is still public is the whole of that story.

Bolt's own database check looks for exactly this: its documentation describes it as finding "a missing row-level security (RLS) policy or a permission that's too open". The plain-language walkthrough for this platform is is your Bolt app safe.

What Bolt's own security audit checks

It reads your project from the inside, and it runs when you press the button.

Bolt announced the audit on 30 July 2026. On a paid plan it sits in the Publish menu as Run security audit: it reviews your code and your database, fixes most problems itself, flags the rest, and does not spend your tokens. On every plan, including Free, the settings of a Bolt database have a Security section that runs the row-level security check described above.

Our scan ran two weeks after that button appeared, so the numbers above cannot say how much it has changed since. What we can say is how the two views fit together. The audit sees your project from the inside, including tables your pages never mention, which a scan from outside never can. A scan from outside sees what a stranger gets from the published app. When an audit finishes, the button reads Security audit up to date, and the next change you publish is one it has not seen.

Run the audit before you publish and look from outside afterwards. If the two ever disagree about whether a table is readable, go with the outside answer, because that is the one a stranger gets.

How to check your own Bolt app

Five things to look at. Use a private window, so your own login does not answer for a stranger.

1. Find out which database you have. New Bolt projects use a Bolt database by default. If you picked Supabase when you created the project, or connected one later, your tables live in a Supabase project you can sign in to.
2. Read the lock on every table. With a Bolt database, open the Security section of your database settings and run the check. With Supabase, open Authentication → Policies and read down the list: a table with row-level security disabled is readable by anyone who has your project address, and that address is in your app. A policy that permits everybody counts as disabled.
3. Search your project for VITE_. Every value behind that prefix is in the window. A project address and a publishable key belong there. A key that bills you belongs in the Secrets panel, read by a server function. If one has ever sat behind the prefix, rotate it with the provider first, because the old value keeps working until you do.
4. Look at your storage. A bucket marked public will list every file in it to anyone who asks, including the ones your app never shows.
5. Or let the scan do it. It runs these from outside along with five more checks, takes about 20 seconds, needs no account, and shows you a grade and what produced it: scan your app free.

Keeping it that way after you publish

A check you ran last month describes last month's app. On Bolt, publishing is one button, so a table added this morning or a key pasted in at midnight is live the moment you press it.

Reeve Monitor runs the nine checks again for you:

• all nine checks every hour, on up to three apps
• whether the app is up, every 60 seconds
• a message when a result changes, so a new finding does not wait for you to look
• a monthly report of what it saw

Monitor is $12 a month at list, with seven days free before it charges you. The pricing page is sometimes below the figure here and never above it.

If your Bolt app keeps its data in your own Supabase project, Reeve Care keeps a copy of it. That includes a project you connected from the start and a Bolt database you have claimed into Supabase.

• an encrypted copy of your Supabase database every night, kept where your project cannot reach it
• each copy verified before it counts, by counting the rows in every table
• a one-click restore when you need one
• your uploaded files as well, once you connect a Storage credential
• everything Monitor does

Care is $49 a month at list for one app, with the same seven days free.

An open table is a thing a stranger can read. A migration that ran the wrong way, or an agent with database access, is a thing that can empty it, and none of the nine checks in this post would bring the rows back. The day an AI agent deleted a production database is what that looks like from the inside.

What to do this week

Start with the VITE_ search, because it is the one finding on Bolt that costs money by itself. If you are still choosing between builders, which AI app builder is safest puts all five side by side.