Why do my Bolt.new environment variables end up visible in the browser?

Bolt.new apps are usually built with Vite, and Vite inlines any environment variable prefixed with VITE_ into the client bundle at build time. Anything with that prefix is public. Real secrets — payment keys, admin tokens, database service keys — must not use the VITE_ prefix and must live on a server or serverless function instead.

Does Bolt.new add authentication to my backend automatically?

No. Bolt.new generates whatever you describe, but it does not guarantee that your API routes or serverless functions check who is calling them. Test each data endpoint while signed out — if it returns data without a valid session, anyone can call it directly.

What is the most common security mistake in a Bolt.new app?

Trusting the front end. Bolt.new produces a convincing UI that hides buttons and routes based on login state, but the underlying API often does not enforce the same rules. An attacker skips the UI and calls the API directly, so every check must be repeated on the server.

How to test a Bolt.new app before your users do

Bolt.new builds and runs a full-stack app right in the browser, then ships it to the web with one click. The catch: the same speed that gets you live also skips the part where someone checks whether the back end trusts the front end. Here's the Bolt-specific test to run first.

What Bolt.new actually gives you

A Bolt.new project is typically a Vite front end (React or Vue) plus whatever backend you asked for — a Supabase project, a Firebase database, or serverless functions deployed to Netlify. Because it's all generated together and runs in a WebContainer, it feels like one seamless thing. But the browser and the backend are still two separate trust zones, and Bolt tends to secure the look of the app (hiding buttons) more reliably than the data (enforcing rules on the server). These eight checks target that gap.

The Bolt.new pre-launch checklist

1. Search your bundle for VITE_ secrets

Open dev tools → Network → reload, and look at your JavaScript bundle. Vite inlines every variable prefixed VITE_ into the browser at build time, so anything with that prefix is public. That's fine for a Supabase URL or a publishable key, but not for a payment secret, admin token, or database service key. Search the source for sk_, service_role, SECRET, and API_KEY. Anything sensitive there must be rotated and moved server-side.

2. Call your API while signed out

In dev tools → Network, find the requests your app makes to load data. Copy one as a fetch, open a fresh private window (no session), and run it. If it still returns data, your backend isn't checking authentication — the UI was the only thing stopping access, and an attacker ignores the UI.

3. Try to reach another user's records

Sign up two accounts. As account A, note a record ID. As account B, request that ID directly through the API. If B gets A's data, you have a broken access-control hole (IDOR). If Bolt wired you to Supabase, this usually means Row Level Security is off or too permissive; if it's a custom backend, the ownership check is missing.

4. Make a stranger sign up

Register in a private window as a first-timer. Does the confirmation email land? Does the verify link work? Try a +-aliased address. Bolt-generated auth flows sometimes look complete but skip email verification entirely — meaning anyone can register as anyone.

5. Feed every form hostile input

Into each field, paste 2,000 characters, emoji, an apostrophe, and <img src=x onerror=alert(1)>. Nothing should crash, and that last payload must render as literal text, not fire an alert. If it fires, you have a cross-site-scripting hole.

6. Follow every button to its end

Bolt is strong at generating screens and weaker at connecting flows across a backend. Walk checkout, billing, and account management all the way through — not just to the first screen. Watch for buttons that look wired but lead to a dead end or a silent failure.

7. Use it on a phone and refresh mid-flow

Shrink to 375px or open on your phone; check nothing overflows and the keyboard doesn't cover inputs. Then start a flow and hit reload halfway — brittle state handling, common in fast-generated apps, loses everything on refresh.

8. Can a user delete their account?

Sign up and try to remove your data entirely. GDPR requires a delete path, and generated apps rarely include one. Confirm that deleting an account actually removes the associated records, not just the login. (See our GDPR checklist.)

If you do only one thing: replay one of your app's data requests in a signed-out window. If it still returns data, your back end trusts the front end — and that's the hole attackers walk through.

The fast way: let something break it for you

Doing all eight by hand every deploy is the chore that doesn't survive a busy week. Blinkof.ai runs them for you: it reads your bundle for exposed secrets, replays your API calls without a session, probes for cross-tenant leaks, tries hostile input, and walks your flows — then returns a report where every fix prompt is written for your actual stack, whether Bolt wired you to Supabase, Firebase, or serverless functions.

It's this checklist, run in under a minute, by something that doesn't assume the UI is the security.