Bolt.new Security

Bolt.new Security Incidents

Common security vulnerabilities and patterns observed in applications built with Bolt.new, including exposed databases, hardcoded API keys, and missing authentication checks.

About Bolt.new Security

Bolt.new by StackBlitz is a popular AI-powered application builder that generates full-stack applications from natural language prompts. While it enables rapid prototyping and deployment, applications generated by Bolt.new consistently exhibit security patterns that leave them vulnerable to common attacks.

These are not unique to Bolt.new — they represent common patterns across AI code generators. However, Bolt.new's focus on instant deployment means these vulnerabilities often go live immediately without security review.

1
Critical
2
High
1
Medium
4
Ongoing

Common Security Patterns

Missing Supabase Row Level Security

critical

Bolt.new-generated applications frequently deploy with Supabase tables that have RLS disabled or no policies configured. This allows anyone with the publicly available anon key to query, modify, or delete data directly from the database, bypassing all application-level authentication.

Technical Details

  • Tables created without ALTER TABLE ... ENABLE ROW LEVEL SECURITY
  • Supabase anon key and URL embedded in client-side JavaScript
  • Direct PostgREST API access allows full CRUD on unprotected tables
  • Application-level auth (login screens, route guards) provides no real protection

Impact

  • Complete database exposure to unauthenticated users
  • User personal data (emails, names, phone numbers) readable by anyone
  • Data manipulation and deletion possible without authentication
  • Regulatory violations (GDPR, CCPA) for apps storing personal data

Hardcoded Third-Party API Keys in Client Bundle

high

Bolt.new commonly places third-party API keys (OpenAI, Stripe secret keys, SendGrid, Twilio) directly in client-side code. Unlike Supabase anon keys which are designed to be public, these keys grant access to paid services and sensitive operations.

Technical Details

  • API keys stored in frontend components or utility files
  • Keys visible in browser DevTools network tab and source code
  • No server-side proxy to protect sensitive API calls
  • Environment variables sometimes exposed via NEXT_PUBLIC_ or VITE_ prefix

Impact

  • Financial loss from unauthorized API usage (OpenAI, cloud services)
  • Stripe secret key exposure allows charge creation and refund manipulation
  • Email service keys enable sending spam or phishing from the app's domain
  • Attacker can exhaust API quotas, causing denial of service

Missing Authentication on API Routes

high

Generated API routes and server functions often lack authentication middleware. Bolt.new creates functional endpoints but does not consistently add authentication verification, allowing unauthenticated access to sensitive operations.

Technical Details

  • API routes generated without auth middleware or token verification
  • Server actions accessible without session validation
  • Admin endpoints not restricted to authorized users
  • Password reset and account management endpoints lack proper verification

Impact

  • Unauthorized access to admin functionality
  • Data exfiltration through unprotected API endpoints
  • Account takeover through unprotected account management routes
  • Privilege escalation by calling admin-only endpoints directly

Overly Permissive CORS Configuration

medium

Bolt.new frequently generates APIs with wildcard CORS headers (Access-Control-Allow-Origin: *), allowing any website to make authenticated requests to the API. This enables cross-site request attacks.

Technical Details

  • CORS set to allow all origins with Access-Control-Allow-Origin: *
  • Credentials allowed with permissive origin settings
  • No origin validation or whitelist implementation
  • Preflight request handling sometimes missing

Impact

  • Cross-site request forgery attacks from malicious websites
  • Data theft through cross-origin requests
  • Session hijacking when combined with credential sharing
  • API abuse from unauthorized origins

What Exposed Bolt.new Code Looks Like

Here is a typical pattern found in Bolt.new generated applications where a Stripe secret key is embedded directly in client-side code:

// VULNERABLE: Bolt.new generated client-side code
import Stripe from 'stripe';

// This secret key is visible to anyone viewing the page source
const stripe = new Stripe('sk_live_51ABC...xyz');

export async function createPayment(amount: number) {
  // This runs in the browser — the key is exposed
  const intent = await stripe.paymentIntents.create({
    amount,
    currency: 'usd',
  });
  return intent;
}

The secure approach moves this to a server-side API route:

// SECURE: Server-side API route
// app/api/payment/route.ts
import Stripe from 'stripe';

// Server-side only — not in the client bundle
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);

export async function POST(req: Request) {
  // Verify authentication first
  const session = await getSession(req);
  if (!session) return new Response('Unauthorized', { status: 401 });

  const { amount } = await req.json();
  const intent = await stripe.paymentIntents.create({
    amount,
    currency: 'usd',
  });
  return Response.json(intent);
}

How VAS Detects These Issues

Vibe App Scanner is purpose-built to detect the security patterns common in AI-generated applications:

Scans client-side JavaScript bundles for exposed API keys (Stripe, OpenAI, SendGrid, etc.)

Distinguishes between intentionally public keys (Supabase anon, Firebase) and leaked secrets

Detects Supabase databases without RLS through direct API probing

Checks for missing authentication middleware on API routes

Identifies overly permissive CORS configurations

Provides specific fix instructions tailored to Bolt.new app architecture

Built with Bolt.new? Scan It.

Check your Bolt.new application for exposed API keys, missing database security, and authentication gaps before attackers find them.

Scan Your App

Frequently Asked Questions

Is Bolt.new safe to use for production apps?

Bolt.new can be used to build production apps, but the generated code requires security review before deployment. Common issues include missing RLS on Supabase tables, hardcoded API keys, and missing authentication checks. Always scan and review AI-generated code before going live.

What are the most common security issues in Bolt.new apps?

The most common issues are: missing Supabase RLS policies allowing direct database access, hardcoded third-party API keys in client-side bundles, missing authentication on API routes, and overly permissive CORS configurations.

Does Bolt.new expose my Supabase database?

Bolt.new includes Supabase configuration (URL and anon key) in client-side code, which is by design. However, if RLS policies are not configured, the database is effectively wide open. Always verify RLS is enabled on all tables.

How do I secure a Bolt.new app before deployment?

Enable RLS on all Supabase tables, move secret API keys to server-side environment variables, add authentication checks to sensitive API routes, configure proper CORS headers, and run a security scan to catch remaining issues.

Last updated: February 2026