Bolt.new app security: find what the build left open

Where Bolt apps get exposed

Bolt is built on StackBlitz WebContainers: Node.js running inside the browser tab. A project usually starts as a Vite app and often adds Supabase for auth and data. Environment variables are handled in a .env file inside the project, and that is the first trap. With Vite, any variable named VITE_something is copied into the JavaScript bundle at build time. If the AI names your OpenAI key VITE_OPENAI_API_KEY so the frontend can call the API directly, the key is now on every visitor’s machine.

The second trap is the same one every Supabase frontend has: the database is reachable from the browser, so access rules must be enforced by RLS. When a query fails during development, the quickest fix the AI finds is often to loosen a policy.

Typical findings on Bolt projects

• Secret API keys (OpenAI, Anthropic, Stripe secret, SendGrid) inside the production bundle because of a VITE_ prefix.
• Source maps published next to the bundle, which hand out the original source code including comments.
• A Supabase table that answers anonymous reads.
• Default hosting headers with no Content-Security-Policy and no clickjacking protection.
• Email spoofing: a custom domain without a DMARC policy.

What Shypset checks on a Bolt app

We detect Bolt from its badge script, *.bolt.new hosting or StackBlitz and Bolt references in the HTML. A mention of bolt.new somewhere inside a JavaScript bundle is not enough, because it is usually just text.

On every scan we read the page and the scripts it loads, the same as a browser does, and run the Public checks: secret patterns in JavaScript, source maps linked by sourceMappingURL, Supabase and Firebase configuration in client code, security headers, TLS, DNS and mail records. Once you verify the domain, we add the Verified checks: probing the Supabase tables the bundle references with the anon key, and looking for files such as /.env or /.git/config that should never be public.

Shypset is a passive external check. It does not log in to your app and does not test application logic such as SQL injection or IDOR, so a clean report means nothing is visible from outside, not that the app is secure.

Fixing it in Bolt

Treat any secret found in the bundle as leaked: rotate it at the provider first, then fix the code. Ask Bolt to move the call that needs the key into a server function (a Supabase Edge Function or the API route of your host) and to keep only public values behind the VITE_ prefix. For source maps, set build.sourcemap to false in the Vite config or stop uploading .map files. Redeploy, then rescan and compare.

Example finding

A Public finding from a Bolt app, as it appears in the report, with its fix prompt.

File: /assets/index-3f9a1c.js
Match: sk-proj-Xr4…[masked]…9QaT
Context: headers:{Authorization:"Bearer "+VITE_OPENAI_API_KEY}

This Bolt project ships the OpenAI key to the browser through the VITE_OPENAI_API_KEY variable. I have already rotated the key. Create a server-side function that calls the OpenAI API with the key read from a server secret named OPENAI_API_KEY, make the frontend call that function instead, and remove every VITE_ variable that holds a secret. Show me which files changed.

Questions

Is a key in my .env file safe in Bolt?

Only if it is used on the server. With Vite, anything prefixed VITE_ is written into the public bundle.

Does Shypset deploy or change my Bolt project?

No. It only reads the deployed site from outside and gives you prompts to apply yourself.