SCAN YOUR BOLT.NEW APP FOR VULNERABILITIES

Bolt.new builds a full-stack app from a prompt inside a StackBlitz WebContainer, then deploys it to Netlify, Vercel, or its own hosting in the same session. A typical Bolt project is a Vite or Next.js frontend, an Express or Hono backend (or serverless functions), a Supabase or Postgres schema, and integration glue for Stripe or OpenAI. The WebContainer sandbox is a genuinely good isolation model — but it protects the browser tab during iteration, not the code once it runs on real infrastructure with real credentials.

That is the gap this scanner targets. Bolt is optimized for “make it work in 30 seconds,” which means wildcard CORS, routes that read userId from the request body, tokens in localStorage, and RLS that was never written. Every one of those works in a one-user demo and becomes a vulnerability the moment the app is public.

Bolt also treats .env as a literal file in the project tree. If the project is shared or public, the secrets in it are readable — so the deployed URL is only half the attack surface. A black-box scan against the running app is what tells you which of these defaults actually shipped.

Common vulnerabilities we find in Bolt.new apps

Exposed keys in source and shared projects

Bolt inlines OPENAI_API_KEY, SUPABASE_SERVICE_ROLE_KEY, and Stripe secret keys into the files it writes, and .env sits in the project tree in plain text. Share the project link and every value is readable; push the repo and the key lives in git history forever, searchable even after rotation. Move every secret to the deploy target’s env system before the first commit, and rotate any key Bolt has ever seen. The Token Leak Checker finds what leaked into the deployed bundle.

Backend routes with no auth or ownership check

Bolt scaffolds an Express route that reads req.body.userId and trusts it — no session check, no ownership check. It works in dev because there is one user; in production it is an IDOR. Sign in as user B, call an endpoint with user A’s ID, and if A’s data comes back you have a BOLA. Pull the user identity from the verified session, never the body, and check ownership before returning anything keyed by ID.

app.get("/api/projects/:id", requireAuth, async (req, res) => {
  const p = await db.projects.findOne({ id: req.params.id });
  if (!p || p.owner_id !== req.user.id) return res.status(403).end();
  res.json(p);
});

Wildcard CORS with credentials

Bolt’s Express, Hono, and Fastify scaffolds ship with cors() and no arguments — Access-Control-Allow-Origin: *. Any site can then read your API from a visitor’s browser. Test it with a one-line fetch() from a different origin; if data comes back, it is too open. Pin the origin to your production domain and reject everything else. See CORS credentials misconfig.

app.use(cors({ origin: ['https://your-app.com'], credentials: true }));

Database shipped without RLS

Bolt wires up Supabase or Postgres and writes queries as if every authenticated user may read every row — because that makes the demo work. With RLS off, one logged-in user reads everyone’s data. Enable RLS on every Supabase table with a per-owner policy (auth.uid() = user_id), or scope rows explicitly in raw SQL; verify with the Supabase RLS Checker.

Missing server-side validation

Generated forms validate with Zod in the React component, then the server trusts the body. The client check is UX; anyone can bypass it with curl. Unvalidated input opens SQL injection on writes and XSS on rendered fields. Re-validate the body, query, and params at the route boundary and reject with a 400 before touching the database.

localStorage tokens and unsanitized LLM output

Bolt stores auth JWTs in localStorage because it is the shortest path to a working login — but any XSS then exfiltrates the token. Bolt’s default markdown renderer also often allows raw HTML, so LLM output containing <img src=x onerror=...> executes on render. Move tokens to HttpOnly; Secure; SameSite=Lax cookies, and sanitize rendered output (react-markdown + rehype-sanitize). See LLM-rendered HTML/markdown.

How VibeEval works with Bolt.new

1. Enter your deployed Bolt URL — wherever it landed (*.netlify.app, *.vercel.app, a custom domain). Optionally add test credentials for authenticated checks.
2. The agent drives a real browser and the API surface. It maps routes, fires cross-origin requests to test CORS, replays authenticated requests with a second user’s IDs to probe BOLA, hits backend routes with no auth header, reads the bundle for exposed keys, and checks security headers.
3. You get a report of findings by severity, each with the request that proved it and a paste-ready fix — the CORS config, the auth middleware, the validation schema — you can feed back into Bolt.

Manual testing vs VibeEval

Manual review still owns the logic Bolt can’t reason about. The scanner wins on repeatability: Bolt rewrites code on every prompt and sometimes reverts a fix when it touches a neighboring file, so the check that counts is the one you can rerun in full after each generation.

Frequently asked questions

Does VibeEval work with any Bolt.new backend?

Yes. VibeEval scans the deployed app regardless of the backend Bolt generated — Node/Express, Hono, serverless functions, Supabase, or raw Postgres — because it tests behavior over HTTP, not source.

Can I scan before deploying?

VibeEval scans deployed apps, since production behavior (real env scopes, real CORS, real headers) differs from the WebContainer preview. For in-editor checks during development, use the Claude Code MCP integration.

How does VibeEval handle pages behind login?

Provide test credentials and the agent runs in authenticated mode, which is also what lets it probe cross-user BOLA by replaying one user’s requests as another.

What makes Bolt apps different to scan?

Bolt is full-stack, so the surface includes backend auth, database policies, CORS, and connection strings — not just the frontend. It also treats .env as a shareable file, so key exposure can happen through the project link, not only the bundle.

Related Bolt.new resources

• How to Secure Bolt — full hardening guide, prototype to production.
• Is Bolt Safe? — the platform’s defaults and what we find on every project.
• Bolt Security Checklist — pre-launch checklist across the full stack.
• Token Leak Checker — find keys exposed in the client bundle.
• CORS Credentials Misconfig — the wildcard-CORS failure in depth.

Test your Bolt.new app before launch

Bolt gets you from prompt to a live URL fast, and every “go fast” default ships with it. Scan the deployed app before you share it — CORS, auth on every route, RLS coverage, and leaked keys, in one pass.