HOW TO SECURE BOLT.NEW - SECURITY GUIDE | VIBEEVAL

Understanding Bolt.new Security

Bolt.new runs your project in WebContainers (Node-in-the-browser) during development, then deploys to a real host (Netlify by default, Vercel or Cloudflare Pages on connect). The security profile is bimodal: WebContainer-only code can’t really hurt you, but the moment you add Supabase, Firebase, Stripe, or a custom backend, every default Bolt picks needs review. The recurring incident shape is “Bolt set up Supabase for me, the demo worked, I shipped, the tables had no RLS.”

Security Checklist

1. Configure backend security rules

If Bolt added Supabase: log into the Supabase dashboard for the project, Database → Tables, enable RLS on every table, and add at least one policy per table (SELECT WHERE auth.uid() = user_id is the common starting point). If Bolt added Firebase: open firestore.rules in the project, replace any allow read, write: if true; with if request.auth != null && request.auth.uid == resource.data.user_id;, then firebase deploy --only firestore:rules. Verify with the Supabase RLS Checker or Firebase Scanner.

2. Enable authentication with verification

In Supabase: Authentication → Providers → Email → Confirm email = on. In Firebase: Authentication → Sign-in method → Email/Password → Email link required = on. Without email verification, a sign-up form is a free account farm — and any password-reset flow becomes an account takeover vector.

3. Audit API keys in the bundle

Open the deployed URL → DevTools → Sources → search for sk_live, sk_test, service_role, AKIA, SG., xoxb-. Bolt sometimes embeds server-side keys when wiring up an integration through the chat interface. Every match needs to be rotated at the provider, removed from the client code, and replaced with a server-side proxy route.

4. Lock down database security rules

Beyond enabling RLS / Firestore rules, write the right rule. The default Bolt-generated Supabase policy is often USING (true) — which enables RLS but allows anyone in. Replace true with the actual ownership predicate. For Firebase, prefer if request.auth.uid == resource.data.user_id over if request.auth != null — the latter lets any authenticated user read any row.

5. Move secrets to environment variables

Use the Bolt environment variable panel for any secret. In the deployed app, only variables prefixed VITE_ (Vite), NEXT_PUBLIC_ (Next), or PUBLIC_ (Astro) reach the browser — everything else stays server-side. Audit every import.meta.env.* and process.env.* reference: if it’s a secret, it must not have one of those public prefixes.

6. Understand WebContainer limits

WebContainers run Node in the browser tab. This means: no real filesystem, no real network privacy, and any “server” you start is reachable only from your tab. The risk is when you copy code from the WebContainer (where everything works) to a real host (where exposed routes are reachable from the internet). Re-test every endpoint after deploy, not just in the StackBlitz preview.

7. Validate form inputs server-side

Bolt-generated forms typically validate in React but accept anything on the server. Add Zod / Valibot validation in your API route or edge function — the schema is also useful documentation. Remember: an attacker doesn’t use your form, they POST to the endpoint directly.

8. Configure CORS for your real frontend domain

Default Bolt-generated APIs ship with Access-Control-Allow-Origin: *. With cookies / credentials enabled, this is a credential-stuffing pivot. Pin to your deployed origin: Access-Control-Allow-Origin: https://your-app.netlify.app. See CORS credentials misconfig for why this matters even when it “works” with *.

9. Audit npm dependencies

Run npm audit against the project after Bolt finishes. AI suggests packages from training data — some are outdated, some are now-deprecated, and a few may not exist on npm at all. The Package Hallucination Scanner flags the AI-specific subset (phantom packages); npm audit covers the CVE-known set.

10. Verify HTTPS on all endpoints

Netlify and Vercel give you HTTPS by default; custom domains may not until you finish the DNS / cert setup. Hit every API route over http:// and confirm it redirects to https://. For HSTS, add Strict-Transport-Security: max-age=31536000; includeSubDomains; preload once the cert chain is stable.

11. Strip stack traces from production errors

In your error handler: in development, log the full error; in production, return {"error": "Internal server error"} and a request ID. Stack traces tell an attacker your runtime version, ORM, and file layout — every piece of recon makes the next attack cheaper.

12. Test with two accounts (BOLA / IDOR)

Sign up as user A, create a resource, copy the URL. Sign up as user B in another browser, paste the URL. If user B sees user A’s resource, your CRUD endpoints are missing ownership checks. This is the most common AI-generated bug after missing RLS — see BOLA in AI-generated CRUD.

13. Run a full security scan

The Vibe Code Scanner catches the AI-specific deploy-side patterns: source maps shipped to prod, .env.example with real keys, exposed /_next/ paths, debug routes left enabled.

Common Vulnerabilities in Bolt.new Apps

Missing Backend Security Rules

The most common Bolt incident: Supabase tables shipped without RLS, or Firebase rules left at allow read, write: if true;. Both make every byte of user data publicly readable with the keys already in your bundle.

Exposed Secrets via Wrong Prefix

A VITE_STRIPE_SECRET_KEY looks fine in the env panel but ships to the browser the moment you reference it from frontend code. The fix is renaming (drop the VITE_ / NEXT_PUBLIC_ prefix) and moving the call to a server route.

Vulnerable / Hallucinated Dependencies

Bolt’s chat may suggest packages that don’t exist on npm or have known CVEs. The phantom-package risk is real: attackers monitor common AI hallucinations and pre-register the names with malicious payloads. Run npm audit and the Package Hallucination Scanner after every dependency add.

Unprotected API Routes

A route file in pages/api/ or app/api/ or netlify/functions/ is publicly reachable the moment it’s deployed — there is no implicit auth. Every handler needs an explicit auth check. AI-generated route files frequently ship with the auth check in a comment but not in the code.

Related Resources

Free Self-Audit Suite

Five free scanners covering RLS, leaked keys, headers, BOLA.

Vibe Coding Security Risk Guide

Full risk catalogue for AI-built apps.

Solo Founder Pre-Launch Checklist

12-step checklist before launch.

Bolt vs Base44 Tech Stack

How the two platforms differ in default security posture.

Automate Your Security Checks

VibeEval scans your Bolt.new application against every category above plus 305 more probes. Findings ship with fix prompts you can paste straight back into Bolt’s chat to remediate.