FixVibe

// docs / security guides / bolt.new checklist

Bolt.new security checklist: 23 items before ship

Bolt.new (StackBlitz WebContainer) runs your dev environment in the browser, generates full-stack JS in minutes, and publishes to Bolt hosting by default or to Netlify (Bolt docs). This checklist targets Bolt-specific risks: secrets that were safe in the dev container leak once the project is exported, Express CORS defaults are permissive, session cookies need explicit HttpOnly flags, and credentials pasted into the terminal or chat are hard to take back. 23 items across secrets, database, auth, headers, deployment, and Bolt-specific gotchas.

PRE = pre-deploy (audit your source). DEPLOY = at deploy time. POST = post-deploy verification.

Secrets and API keys (5 items)

Bolt's WebContainer runs in the browser; exporting to GitHub or Netlify moves secrets from the isolated container into the public repo.

  1. PRE — Never paste service-role keys into the Bolt terminal or chat. Anything you paste there is hard to take back. Keep keys in .env or your host's environment settings instead.
  2. PRE — Create a .env file, never hardcode secrets in code. Bolt's dev container isolates .env nicely, but when you export to GitHub, .env must be in .gitignore.
  3. PRE — Confirm .gitignore excludes .env, .env.local, .env.*.local. Bolt usually scaffolds this correctly, but verify before export.
  4. DEPLOY — Set secrets in Netlify Environment Variables, not in code. Netlify → Site settings → Build & deploy → Environment. Add your keys there, scoped to Production.
  5. POST — Run Secrets in JavaScript Bundles on the deployed URL. If a key reached the Netlify deploy, the scan will find it.

Database access control (3 items)

Bolt usually scaffolds with Supabase or Convex. Both have default-open modes that need explicit policies.

  1. PRE — If using Supabase, enable RLS on every public table. Bolt's scaffold might not include ENABLE ROW LEVEL SECURITY or policies. Add both in the migration.
  2. PRE — Write policies that validate user ownership. Every policy should check auth.uid() = user_id or equivalent. Bolt's generated policies sometimes miss this.
  3. POST — Run a FixVibe scan on the deployed app. Check the Supabase Row-Level Security result: it shows any table an anonymous visitor can read with your public key.

Authentication and sessions (4 items)

Bolt generates Express or Next.js auth. The risk is in cookie configuration and token validation.

  1. PRE — Ensure session cookies are HttpOnly; Secure; SameSite=Lax. Bolt sometimes generates cookies without these flags. Manually verify or add them.
  2. PRE — Check Bolt's generated auth handlers for server-side token verification. If getSession() is used, replace with verified backend lookup.
  3. PRE — Verify the sign-in redirect guard. The next param must start with /, never //. Bolt sometimes skips this; add it manually if needed.
  4. POST — Test logout clears the session cookie. Sign in, sign out, inspect cookies. The session cookie must be deleted on logout.

HTTP headers and CSP (3 items)

Bolt's Express/Next.js scaffolds rarely include CSP. Static hosts need explicit config.

  1. PRE — Add middleware for security headers if using Express. Bolt's Express scaffold needs manual middleware for CSP, HSTS, X-Frame-Options.
  2. PRE — If using Next.js, ensure src/middleware.ts exists with CSP. Bolt might scaffold it, but verify the CSP nonce logic is correct.
  3. POST — Run HTTP Security Headers on the deployed Netlify URL. The scan reports missing headers.

Deployment hygiene (5 items)

Bolt exports to GitHub and Netlify. Both need careful configuration.

  1. DEPLOY — Ensure Bolt exports include .gitignore with .env listed. Verify the GitHub repo doesn't have .env files after export.
  2. DEPLOY — Set Netlify env vars via Site settings, not GitHub secrets. Netlify's Environment Variables are encrypted at rest; GitHub secrets are designed for CI, not deployment.
  3. DEPLOY — Audit the Netlify deploy log for secret echo. If the build log prints any env var, it's compromised.
  4. DEPLOY — Configure Netlify build command to not run echo $SECRET. Check your package.json and build scripts for any secret output.
  5. POST — Verify Netlify redirect for HTTP → HTTPS exists. Bolt apps should force HTTPS. Netlify can enforce this via settings.

Bolt-specific gotchas (3 items)

Patterns unique to Bolt's WebContainer-to-export flow:

  1. WebContainer isolation is lost on export. Bolt's dev environment securely isolates secrets, but once you export to GitHub, you're responsible for .gitignore and env-var discipline.
  2. Treat the terminal and chat like a shared log. Don't paste credentials into either; put them in .env or your host's environment settings.
  3. Express cors({ origin: '*' }) is the default. Bolt's Express scaffold often includes permissive CORS. Replace with cors({ origin: 'https://yourdomain.com', credentials: true }).

Next steps

Review the general vibe coding security checklist for 51 cross-tool items. See step-by-step hardening for CSP, RLS, and auth patterns.

// scan your app

Stop reading. Start finding the gaps in yours.

Drop in a URL — FixVibe runs every passive check from this guide plus the rest of its 230+ passive checks, usually in under a minute. Free, no install, no card.

  • Free tier — 3 scans / month, no card.
  • Passive scans against any URL — no domain verification needed.
  • Tuned for Cursor, Claude Code, Lovable, Bolt, v0, Replit.
  • Coding-agent prompts for code/config findings, plus operator steps for DNS/provider fixes.
Run a free scan →

no signup required

Bolt.new security checklist: 23 items before ship · FixVibe