Bolt Security: How to Secure an App Built with Bolt.new
Bolt.new, StackBlitz's AI app builder, generates and runs full-stack applications entirely from a prompt — scaffold, dependencies, dev server, and deployment in minutes. That end-to-end speed is exactly why Bolt apps need a deliberate security pass before launch: the app goes from first prompt to public URL without a code review, a threat model, or anyone asking what happens when input is hostile. The result is a recognizable set of gaps we see when scanning Bolt-built apps — secrets in the client bundle, wide-open CORS, endpoints that trust their input. Here is what to look for and how to fix it.
Security patterns we commonly find in Bolt-built apps
These are the issues that appear most consistently when we scan applications built with Bolt. Each one is fixable — the checklist below walks through them in priority order.
Shipping without any security review
Bolt's core promise — prompt to deployed app in one sitting — means the traditional checkpoints where security review happens simply don't occur. The scaffold, the auth flow, the API surface, and the deployment config are all machine-generated and typically unread by a human before real users arrive. Nothing is wrong with any single step; the missing step is the review.
Environment variables exposed in client bundles
Bolt apps are frequently built on Vite, where any env var prefixed VITE_ is compiled into the public JavaScript bundle. Generated code that needs a key on the client will happily use that prefix for OpenAI, Supabase service, or payment credentials — and once bundled, the secret ships to every visitor. Grep your built output before every deploy.
Missing input validation on generated endpoints
Generated API routes tend to destructure the request body and use the values directly — in database queries, file paths, fetch URLs, or third-party API calls. Without schema validation, type checks, and length limits, those endpoints are exposed to injection, path traversal, SSRF, and plain data corruption from the first malformed request.
Default CORS left wide open
Access-Control-Allow-Origin: * appears constantly in generated backends, because it makes the frontend work during development on the first try. Left in production — especially combined with credentialed requests or token-bearing APIs — it lets any website on the internet script requests against your backend from its visitors' browsers.
No Content-Security-Policy or security headers
Generated Bolt apps virtually never set CSP, X-Frame-Options, X-Content-Type-Options, or Strict-Transport-Security, because nothing in a feature prompt asks for them. Without CSP, any XSS flaw in the generated UI escalates unimpeded; without the others, clickjacking and MIME-sniffing attacks stay on the table.
Auth added as an afterthought
Prompt-built apps often start authless — a demo, a tool, a landing page — and grow user accounts later. Auth retrofitted by follow-up prompts commonly protects the pages but not the API routes behind them, or checks that a user is logged in without checking what they own. Every endpoint added before auth existed needs a second look.
How to secure a Bolt app: step-by-step checklist
Work through these steps before launch, and re-run them after any major AI-generated change.
- 1
Grep your built client bundle (the dist or build output, not just the source) for secrets: sk-, sk_live, service_role, whsec_, and any VITE_-prefixed variable holding a private credential. Anything found ships to every visitor — rotate it and move the call server-side.
- 2
Audit which env vars use the VITE_ (or equivalent public) prefix. Only values that are safe to publish belong there; everything else must be read server-side only.
- 3
Add schema validation (e.g. zod) to every API endpoint the generator created: validate types, lengths, and allowed values on the request body, query params, and headers before any value reaches a query, file path, or outbound fetch.
- 4
Replace Access-Control-Allow-Origin: * with an explicit allowlist of your own origins, and do not combine wildcards with credentialed requests.
- 5
Set security headers on the deployment: Content-Security-Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy, and Strict-Transport-Security.
- 6
Walk every API route and confirm it enforces both authentication and resource ownership — especially routes generated before auth was added to the app.
- 7
Check database access for string-concatenated queries and replace them with parameterized queries or an ORM; check any generated file-handling code for path traversal.
- 8
Run npm audit on the generated dependency tree and update packages with known CVEs — generated lockfiles can pin stale versions.
- 9
Deploy to a staging URL and run a Vuln0x scan; fix Critical and High findings, re-scan to confirm, and only then announce the app.
Securing Bolt-built apps in practice
The defining security property of a Bolt-built app is that it reaches the internet without passing through the rituals that normally catch mistakes. There is no pull request, no second pair of eyes, no staging period where someone idly pokes at the API — the person who prompted the app is usually the only human who has seen any of it, and they have mostly seen the UI. So the first, most valuable thing you can do costs nothing: read the generated backend. Open every file in the API or server directory and ask of each endpoint — who can call this, what do they control, and where do those values go? Most of the findings in this page's checklist are visible within thirty minutes of that exercise.
The client bundle deserves particular paranoia because bundlers make secret exposure silent. In a Vite-based Bolt app, the VITE_ prefix is a one-way door: any variable carrying it is string-substituted into the JavaScript your CDN serves to the world. Generated code chooses that prefix whenever it wants a value available in the browser, and an API key used in a client-side fetch works perfectly — which is exactly why nobody notices. Make it a pre-deploy habit to search the built output itself for key-shaped strings. If a third-party API requires a secret, the call belongs in a server route, with the browser talking only to your backend.
Configuration defaults are the other silent risk. Wide-open CORS, absent CSP, missing security headers, verbose error responses — none of these break anything, so generated apps ship with all of them, and each one removes a layer that would have contained a future mistake. The fix is mechanical and takes minutes: an explicit CORS origin list, a baseline header set on the hosting platform, and production error handling that logs details server-side while returning generic messages. Do it once, and every subsequent prompt-driven feature lands inside a hardened shell instead of an open one.
Finally, verify from the outside. Reading code catches design flaws; only probing the deployed app catches what actually made it to production — the header that the host didn't apply, the debug route that survived, the secret that a rebuild reintroduced into the bundle. Vuln0x scans your live URL with 40+ engines covering OWASP Top 10 vulnerabilities, exposed secrets and files, CORS and header misconfigurations, and returns a graded report in about a minute. For a prompt-built app, that scan is the closest thing to the security review the workflow skipped — run it before launch and after every significant regeneration.
More vibe coding security guides
Return to the vibe coding security hub or explore guides for other AI app builders below.
Frequently asked questions about Bolt security
- Are apps built with Bolt.new secure?
- A Bolt-built app is as secure as the review it gets, and by default it gets none — the workflow goes from prompt to deployed URL without a human reading the backend. The generated code commonly ships with permissive CORS, no security headers, unvalidated inputs, and occasionally secrets in the client bundle. None of that is inherent to Bolt; it is what unreviewed generated code looks like on any platform. A focused audit plus an external scan closes most of the gap quickly.
- How do environment variables leak in Bolt apps?
- Most Bolt apps use Vite, and Vite compiles any variable prefixed VITE_ directly into the public JavaScript bundle so the browser can use it. When generated code needs an API key client-side, it uses that prefix, and the key ships to every visitor — the app works, so nothing looks wrong. Check by searching your built output (not just source) for key patterns like sk- or service_role. Real secrets belong in server-only env vars, used by server routes the browser calls.
- Why is Access-Control-Allow-Origin: * a problem?
- A wildcard CORS policy tells browsers that any website may make requests to your API and read the responses. During development it conveniently silences cross-origin errors, which is why generated code uses it — but in production it means a malicious page visited by your user can script requests against your backend from their browser. Replace it with an explicit list of your own origins, and never combine a wildcard with credentialed requests.
- What should I check first in a Bolt-generated backend?
- Three things, in order. First, secrets: search the built client bundle for API keys and rotate anything you find. Second, input handling: every endpoint should validate the request body and parameters with a schema before using them in queries, file paths, or outbound requests. Third, access control: every route that reads or writes user data must check both that a user is logged in and that they own the resource in question. Those three categories cover the majority of serious findings in Bolt apps.
- How do I scan a Bolt.new app for vulnerabilities?
- Deploy the app, then run its public URL through Vuln0x. The free scan needs no installation, runs 40+ engines against the live deployment — checking OWASP Top 10 issues, exposed secrets, CORS and security-header misconfigurations, and reachable sensitive files — and returns a graded report with prioritized remediation in about a minute. The free tier includes 50 credits, so you can re-scan after each fix to confirm it closed.
Scan your Bolt-built app for free
No installation, no credit card. Paste your URL and get a graded security report in under 60 seconds — built for AI-generated apps.