A Bolt.new app is generated and deployed fast enough that security review is easy to skip entirely between prompt and production. The most common gaps are the same ones any rapidly scaffolded app ships: environment variables or API keys reachable in the compiled frontend bundle, no security headers set, and no verification that a backend's access rules match what the UI implies.
Why this happens in Bolt.new apps
Bolt.new's speed is the whole point: prompt to a running, deployed app in one flow. That same speed means there's no natural checkpoint where someone reviews what got shipped to the public internet before it's live.
A traditional deploy pipeline has a build step, a review, sometimes a staging environment. Bolt.new collapses all of that into one continuous action, which is exactly what makes it useful, and exactly why a security pass has to be something you deliberately add back in.
Common issues in Bolt.new apps
What actually shows up when a Bolt.new app gets checked:
- Secrets compiled into the client bundle: any environment variable referenced from client-side code ships to the browser exactly as written, including keys only meant for a server-side call the generated code happened to make client-side.
- No security headers configured: generated deploy configs default to whatever the underlying framework ships with, which for most frameworks means no CSP, HSTS, or frame-protection headers unless explicitly added.
- Backend access rules not reviewed: if the generated backend uses a BaaS provider, its default access rules may not match what the generated frontend's auth flow implies; the UI can look gated while the API underneath isn't.
How to fix it
A quick pass before the link goes anywhere public:
- Grep the built bundle (or the browser devtools Network/Sources tab) for any key or secret that shouldn't be client-visible, then move it server-side.
- Add security headers explicitly: most frameworks support a config-level headers() call rather than needing a separate proxy.
- Independently verify the backend's actual access rules against the target domain, not just what the generated frontend's flow implies.
Frequently asked
Is a Bolt.new preview URL as exposed as the deployed one?
Yes. A preview URL is a live, publicly reachable deployment like any other. Anything wrong with secrets, headers, or backend rules is just as reachable there as on a custom domain.
Does removing a key from the visible source fix the leak?
No. If a key was ever served in a bundle a browser fetched, treat it as compromised. Rotate it. Removing it from the current build doesn't undo requests already made against the old, still-valid key.