Is your Bolt.new app secure?

Bolt.new builds and deploys full-stack apps from a prompt. The speed is real, but generated code tends to optimise for "it works" rather than "it is safe". These are the issues worth checking before you share the link.

Common security risks in Bolt apps

1. 1. Secret keys bundled into the front end

   Environment variables with a public prefix (VITE_, NEXT_PUBLIC_) are copied into the JavaScript every visitor downloads. If a secret key was given one of those prefixes to "make it work", it is public now.

2. 2. Database rules that allow everyone

   When the app uses Supabase or Firebase from the browser, Row Level Security or Firebase Security Rules are the only thing standing between a visitor and your whole database. Test-mode rules left in production are a common cause of leaks.

3. 3. Files that should never be public

   A deployed .env, .git folder, package.json or source map hands an attacker your configuration, history or original code.

4. 4. API routes without authentication

   Generated API routes sometimes answer anonymous requests that should require a login, and rarely include rate limiting, which makes scraping and cost abuse easy.

5. 5. No security headers

   Default deploys usually lack Content-Security-Policy, HSTS and anti-clickjacking headers.

What a FixPrompt scan checks

Passive checks on your public site, the same way a visitor's browser loads it. No attacks, no logins, no data queried.

• Secret key patterns for 30+ providers in JavaScript bundles, plus Supabase privileged keys
• Public .env, .git, package.json, backup files and source maps
• Common API paths that answer anonymous requests with JSON, and missing rate-limit headers
• Supabase and Firebase projects flagged for an RLS / security rules review (no data is queried)
• Content-Security-Policy, HSTS, clickjacking and MIME-sniffing headers

Copy-paste fix prompt

Paste this into Claude Code, Cursor, Codex or any coding agent with access to your repository. A scan gives you a prompt tailored to the issues found on your live site.

Audit this Bolt.new project for security issues and fix them in priority order:

1. List every environment variable with a public prefix (VITE_, NEXT_PUBLIC_, PUBLIC_). If any holds a secret, move its usage to a server route or function and rotate the key.
2. If the app uses Supabase or Firebase from the browser, enable Row Level Security (or Firebase Security Rules) and limit every table or collection to its owner.
3. Make sure .env files, the .git folder and source maps are not deployed.
4. Require authentication on every API route that returns private data and add basic rate limiting.
5. Add Content-Security-Policy, Strict-Transport-Security, frame-ancestors, X-Content-Type-Options and Referrer-Policy headers.

Explain each change and how to verify it.

FAQ

Is a Bolt.new app secure by default?

It can be, but nothing checks it for you. Secret handling, database rules and headers depend on the code that was generated, so review them before real users sign up.

Why is my API key visible in the browser?

Variables with a public prefix like VITE_ or NEXT_PUBLIC_ are bundled into the front end. Keep secrets in unprefixed variables that only server code reads.

Does the scan attack my app?

No. FixPrompt loads public pages and a short list of well-known paths, one normal request each. It never sends exploit payloads or tries credentials.