Bolt.new Security Vulnerabilities: What Our Scanner Finds Most Often

Bolt.new produces working full-stack apps in minutes. It also produces, at statistically predictable rates, apps that fail basic security checks. This article breaks down the specific vulnerability classes we find in Bolt.new output, with frequency data and the exact prompts that fix each one.

This is not a "Bolt is bad" argument. It is a map of the gap between "deployed" and "safe." Close the gap, ship with confidence.

TL;DR for the Busy

• Bolt.new apps average 4-6 findings on a VibeArmor scan, with 1-2 of them at Tier 1 severity (exploitable today).
• The top three issue classes are exposed Supabase keys with broken RLS, missing rate limiting, and absent security headers.
• Most Bolt.new apps move from F to B+ after 4-5 specific fixes, most of which take under 30 minutes each.
• Bolt.new's strength (instant full-stack scaffolding) is also its exposure vector: generated code ships before a human can audit it.

The Vulnerabilities We Find Most Often

1. Supabase Anon Key with Broken Row Level Security (64% of scans)

Bolt.new frequently uses Supabase as the backend. The anon key is designed to be public — you cannot hide it because the browser needs it. The security model depends on Row Level Security policies blocking unauthorized queries at the database layer. Bolt generates RLS policies, but often with USING(true), which grants access to every role including anonymous users.

How to test: Open your deployed app in an incognito window. Open DevTools Console. Run:

const supabase = window.supabaseClient || /* grab from your app */;
const { data } = await supabase.from('users').select('*');
console.log(data);

If you see data from users other than yourself, your RLS is broken.

Fix prompt for Bolt: "Audit every RLS policy. Replace any USING(true) with explicit auth.uid() checks. Every UPDATE policy must have a WITH CHECK clause that prevents users from modifying fields they should not control (role, is_admin, org_id, etc.)."

2. Missing Rate Limiting (81% of scans)

Bolt.new generates auth flows that work correctly but do not rate-limit. An attacker can try thousands of passwords per minute against your login endpoint, or abuse your OpenAI-backed API to run up your bill.

Fix prompt: "Add rate limiting using Upstash Redis. Limit login attempts to 5 per minute per IP. Limit all /api/* routes to 60 requests per minute per IP. Return 429 status code when limits are exceeded."

3. No Content-Security-Policy Header (86% of scans)

Without CSP, any XSS vulnerability becomes instant data exfiltration. Bolt.new does not add this header by default. Even a loose CSP is infinitely better than none.

Fix prompt: "Add a Content-Security-Policy header via middleware. Start with default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://*.supabase.co; connect-src 'self' https://*.supabase.co https://api.openai.com; then tighten over time."

4. Exposed API Keys in Client Bundle (33% of scans)

Bolt.new sometimes treats non-Supabase keys (OpenAI, Stripe, SendGrid) like they can be safely exposed to the client. They cannot. If your app calls the OpenAI API directly from the browser, the API key is in the JavaScript bundle and anyone can extract it.

How to test: Open DevTools → Sources. Search for sk_live, sk-, SG., OPENAI. Anything you find is leaked.

Fix prompt: "Move all third-party API calls to server-side API routes. Remove NEXT_PUBLIC_ prefix from any secret key. Rotate any key that was previously exposed in client code."

5. Unprotected Admin Routes (27% of scans)

Bolt generates admin pages with client-side auth checks. The API routes behind those pages often have no auth at all. An attacker can call the admin API directly without ever loading the UI.

How to test: Find your admin routes (/admin, /api/admin/*). Open each in an incognito window. Any page or API that returns 200 without authentication is exploitable.

Fix prompt: "Add server-side auth checks on every /api/admin/* route. Use middleware.ts to redirect unauthenticated users from /admin pages. Do not rely on client-side state to hide admin features."

6. Wildcard CORS (38% of scans)

Access-Control-Allow-Origin: * means any website can make authenticated requests to your API on behalf of your logged-in users. Bolt.new sometimes sets this to enable cross-origin calls during development and forgets to restrict it in production.

Fix prompt: "Set Access-Control-Allow-Origin to the exact production domain. Remove wildcard CORS. If multiple origins need access, whitelist them explicitly in middleware."

7. No CSRF Protection on State-Changing Routes (22% of scans)

Bolt.new generates API routes that accept POST/PUT/DELETE without CSRF tokens. Combined with cookie-based auth, this lets attackers make authenticated requests from other sites.

Fix prompt: "Add CSRF protection to every state-changing API route. Either use SameSite=Strict cookies for auth tokens, or add a CSRF token check to all POST/PUT/DELETE routes."

Why Bolt.new Produces These Patterns

Bolt.new's value proposition is speed: typing a prompt and seeing a working app in minutes. To deliver on that, it optimizes for "the app runs" rather than "the app is hardened." Security features that would add friction (rate limiting that slows down your own testing, CSP that blocks your inline scripts during iteration) get skipped by default.

This is a reasonable product decision. Bolt.new is a prototyping tool. The failure mode is treating the prototype as production without a security pass. The platform builds fast, but your deploy-to-users workflow needs a gate between "Bolt finished" and "real users can touch this."

Compared to Cursor, Lovable, and v0, Bolt.new's vulnerability distribution is similar. The specific framework matters less than the workflow. Apps that ship straight from AI output to production have these issues regardless of which tool generated them.

The Hardening Workflow

Here is the exact workflow we recommend for Bolt.new apps:

1. Build with Bolt until the app does what you want.
2. Scan with VibeArmor to see what was missed.
3. Fix the Tier 1 findings first using the fix prompts above (exposed secrets, broken RLS, unprotected admin routes).
4. Fix Tier 2 findings next (rate limiting, CSP, CORS, CSRF).
5. Re-scan to confirm fixes landed and no regressions were introduced.
6. Ship.

The whole loop takes 2-4 hours for a typical Bolt.new app. That is a one-time cost. After the initial hardening, new features tend to inherit the security patterns you established (middleware, rate limiters, CSP) so subsequent deploys do not re-introduce the same issues.

A Real Example

We recently scanned a Bolt.new-built SaaS for managing freelance invoices. Initial scan: F grade, 6 findings. The owner ran fix prompts back through Bolt for each finding, then re-scanned. Post-fix scan: B+, 1 informational finding (server header disclosure, Tier 3).

Time to fix: 90 minutes. The app now handles live payment data. Same platform, same generator, completely different security posture. The difference is a scan and a handful of fix prompts.

Scan Your Bolt.new App

Paste your Bolt.new URL. Get a 3-minute scan showing exactly which of these patterns your app ships with, plus the fix prompt for each finding.

Scan your Bolt.new app free →

For broader context, see the 15-item vibe coding security checklist and the step-by-step hardening guide.

Frequently Asked Questions

Is Bolt.new less secure than Cursor or Lovable?

Across our scans, the three platforms produce apps with similar vulnerability rates. Bolt.new and Lovable tend to have slightly higher RLS misconfig rates because they lean heavily on Supabase. Cursor apps have more varied backends, so the vulnerability distribution spreads out. Overall vulnerability count is within a few percentage points.

Can I ask Bolt.new to generate secure code from the start?

Partially. Prompts like "include Row Level Security with explicit auth.uid() checks" and "add rate limiting using Upstash" do improve the generated output. But Bolt will still skip things you did not ask for. A better workflow is scan-then-fix: let Bolt build freely, then use the scan report to close the specific gaps that appeared.

Do these same issues exist in self-hosted Bolt?

Yes. The vulnerabilities are in the generated code, not in Bolt.new's hosted infrastructure. Whether you run Bolt at bolt.new or self-host the open-source version, the output has the same patterns and needs the same review.

How does VibeArmor compare to Bolt's built-in security features?

Bolt.new does not ship built-in security scanning. You can ask Bolt to review its own code ("check this app for security issues") but it tends to produce generic advice rather than finding specific exploitable issues. VibeArmor runs 120 targeted checks including live probing of RLS policies, JavaScript bundle analysis, and automated authentication bypass testing. The XBOW benchmark (104/104) validates detection accuracy on a standard adversarial corpus.

What about Bolt.new's paid tier — is that more secure?

Bolt's paid tiers unlock more usage and features, not different code generation. The security characteristics of generated apps are the same across free and paid plans. What changes your security posture is the review step, not the Bolt tier.