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.
Common Security Patterns
Missing Supabase Row Level Security
criticalBolt.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
highBolt.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
highGenerated 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
mediumBolt.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 AppFrequently 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.
Related Security Resources
Last updated: February 2026