Bolt.new Security Guide: 7 Vulnerabilities to Fix Before Launch
Bolt.new lets you build full-stack apps in the browser - but its speed hides 7 critical security vulnerabilities. From exposed API keys to missing auth, here's everything you need to fix before launch.
By Paula C · Kraftwire Software
· 9 min readWhy Bolt.new Apps Need a Security Audit
Bolt.new from StackBlitz is one of the fastest ways to build a web application. Describe your idea, and Bolt generates a full-stack app running in a WebContainer - right in your browser. No local setup, no deployment pipeline, just instant results.
But that instant gratification comes with a hidden cost. The AI behind Bolt.new optimizes for one thing: **making your app work as quickly as possible**. Security is rarely part of that equation. And because Bolt handles everything from package installation to deployment, many developers never review the code it generates.
We've scanned hundreds of Bolt.new apps through SimplyScan. Here are the 7 most critical vulnerabilities we find, ranked by severity and frequency.
---
The 7 Critical Bolt.new Vulnerabilities
1. API Keys Bundled in Client-Side JavaScript
This is the most common and most dangerous issue in Bolt.new apps. When you tell Bolt to "add OpenAI chat" or "connect to Supabase," it places the API key directly in your component or utility file. Since Bolt apps are client-side by default, that key gets bundled into the JavaScript that's sent to every user's browser.
**What attackers do with exposed keys:**
**OpenAI/Anthropic keys**: Generate thousands of dollars in API charges within hours
**Stripe secret keys**: Issue fraudulent refunds, create charges, or access customer data
**Supabase service-role keys**: Bypass all database security and read/write any table
**SendGrid/Mailgun keys**: Send phishing emails from your verified domain
**Database connection strings**: Direct access to your entire database
**How to detect it:**
Open your deployed app in a browser
Go to DevTools → Sources → look through the JavaScript bundles
Search for patterns like `sk-`, `sk_live_`, `service_role`, `Bearer`, `apiKey`
**How to fix it:**
Move all secret keys to server-side Edge Functions or API routes
Use only publishable/anon keys in the frontend (like Supabase's anon key)
If a secret was ever in client code, **rotate it immediately**
Use SimplyScan to automatically detect exposed keys in your deployed app
2. Missing Row-Level Security (RLS) Policies
When Bolt creates Supabase tables, it enables RLS but often leaves it without any policies. This creates a false sense of security - RLS is "on" but effectively does nothing useful. In some cases, the policies are too broad (e.g., allowing any authenticated user to read all rows).
**The danger:** Without proper RLS:
Any user can read every other user's data by querying the table directly
Users can modify or delete records that don't belong to them
An attacker with your anon key can access the entire database through the Supabase API
Even "authenticated-only" policies fail if they don't scope by `auth.uid()`
**Common RLS mistakes in Bolt apps:**
Tables with RLS enabled but zero policies (effectively blocks all access, causing bugs that lead devs to disable RLS entirely)
Policies that check `auth.uid() IS NOT NULL` instead of `auth.uid() = user_id`
Missing policies for UPDATE and DELETE operations
No policies on junction tables or metadata tables
**How to fix it:**
Review every table in your Supabase dashboard
Add SELECT, INSERT, UPDATE, and DELETE policies for each table
Always scope policies to the current user: `USING (auth.uid() = user_id)`
Test by logging in as one user and trying to access another user's data
Use the SimplyScan Pro scan to detect missing or weak RLS policies
3. No Authentication on Protected Routes
Bolt builds beautiful UIs fast, but it rarely adds authentication guards to routes that need them. Admin dashboards, settings pages, user profiles, and data management interfaces are often accessible without logging in.
**Why it happens:** Bolt responds to what you ask for. If you say "create a dashboard showing all orders," it builds the dashboard and connects it to your database. It doesn't add a login flow because you didn't mention one.
**The risk:** Once deployed, anyone who discovers your URL can:
View sensitive business data (orders, users, revenue)
Access admin functionality (create/delete users, change settings)
Modify records through unprotected API endpoints
Download data exports
**How to fix it:**
Add authentication before building any other feature
Use Supabase Auth, Clerk, or Auth0 for production-ready auth
Wrap protected routes in an auth check component
Verify authentication on the server side (not just in React components)
Add loading states while checking auth to prevent flash-of-content
4. Exposed Supabase Database Details
Bolt apps using Supabase expose the project URL and anon key in the client bundle (this is expected and safe by design). However, Bolt sometimes also exposes:
The full database connection string
The service-role key
Internal table structures through error messages
RPC function names and parameters
**Why it's dangerous:** While the anon key is meant to be public, the service-role key and database connection string are not. The service-role key bypasses all RLS, giving full database access. The connection string provides direct PostgreSQL access.
**How to fix it:**
Verify only the anon key and project URL are in client code
Search for `service_role`, `postgres://`, `postgresql://` in your codebase
Never log database errors to the client - catch them and return generic messages
Use Edge Functions for any operation that requires elevated privileges
5. Vulnerable Dependencies
Bolt.new installs npm packages automatically based on AI suggestions. These packages may:
Be outdated versions with known CVEs
Include unnecessary sub-dependencies that increase attack surface
Be the wrong package entirely (typosquatting)
**Real-world impact:** In 2025, several popular npm packages were found to contain malware or critical vulnerabilities. If Bolt installs an affected version, your app inherits those vulnerabilities.
**How to fix it:**
Run `npm audit` after generating your app
Update all packages to their latest versions
Remove packages you're not actually using
Be suspicious of packages with very few downloads or recent name changes
Use SimplyScan to detect vulnerable dependencies in your deployed app
6. Client-Side Authorization Logic
Bolt frequently implements access control in React components rather than on the server. Common patterns include:
Checking `user.role === "admin"` in JSX to conditionally render admin features
Using localStorage to store user permissions
Hiding UI elements instead of restricting API access
Feature flags checked in the browser
**Why it's dangerous:** Client-side code is entirely under the user's control. An attacker can:
Modify React state in browser DevTools to grant themselves admin access
Call API endpoints directly, bypassing any UI-level restrictions
Modify localStorage values to change their role
View "hidden" content by disabling the conditional rendering
**How to fix it:**
Enforce all authorization on the server (Edge Functions, RLS policies, middleware)
Use RLS policies with `has_role()` functions for database-level access control
Store roles in a protected `user_roles` table (not in `localStorage` or `profiles`)
Treat client-side checks as UX conveniences, never as security boundaries
7. Missing Security Headers and HTTPS Configuration
Bolt-generated apps deployed to various hosting platforms often lack critical security headers. These headers prevent common attacks and are expected by security scanners and browsers.
**Missing headers we commonly find:**
No `Content-Security-Policy` - allows XSS attacks
No `X-Frame-Options` - allows clickjacking
No `Strict-Transport-Security` - allows HTTPS downgrade attacks
No `X-Content-Type-Options` - allows MIME sniffing attacks
**How to fix it:**
Configure headers in your hosting provider (Vercel: `vercel.json`, Netlify: `_headers`)
Start with a strict CSP and loosen only as needed
Enable HSTS with a long max-age
Add `X-Frame-Options: DENY` unless you need iframe embedding
Test your headers at securityheaders.com
---
Your Bolt.new Security Checklist
Before launching any Bolt.new app:
✅ No secret keys in client-side code (only anon/publishable keys)
✅ RLS enabled with specific policies on every table
✅ Authentication required on all non-public routes
✅ Auth verified server-side, not just in React
✅ No service-role key or database connection string in frontend
✅ All dependencies audited (`npm audit` clean)
✅ Authorization enforced at the database level
✅ Security headers configured on hosting platform
✅ Error messages don't expose internal details
✅ File uploads validated for type and size
---
Scan Before You Ship
SimplyScan checks your Bolt.new app against 51+ security and performance criteria in 30 seconds. Free scans cover the essentials; Pro scans go deeper with GitHub repository analysis.
[Scan your Bolt.new app now →](/)