TL;DR
Bolt.new creates full-stack applications from prompts, often including databases. The biggest risks are hardcoded API keys, missing database security (especially if using Supabase without RLS), and unprotected API endpoints. Before deploying, review all environment variables, enable Row Level Security on any database, and add authentication to routes that need it.
Understanding Bolt.new's Architecture
Bolt.new generates complete applications that typically include:
- Frontend: React or similar framework
- Backend: API routes or serverless functions
- Database: Often Supabase, Firebase, or similar
- Hosting: Can deploy to various platforms
This full-stack approach means security concerns span multiple layers. Each component needs attention.
The Most Common Bolt.new Security Issues
1. Hardcoded API Keys
Bolt often generates code with placeholder or example API keys that need replacement:
// DANGEROUS: Hardcoded keys
const supabase = createClient(
'https://xxxxx.supabase.co',
'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...' // Hardcoded!
);
const stripe = new Stripe('sk_test_abc123...'); // In code!
const openai = new OpenAI({ apiKey: 'sk-...' }); // Exposed!
// SAFE: Environment variables
const supabase = createClient(
process.env.SUPABASE_URL,
process.env.SUPABASE_ANON_KEY
);
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);
const openai = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });
Search your entire codebase for strings starting with sk_, pk_, api_, or containing key, secret, token, or password.
2. Missing Database Security (Supabase RLS)
If Bolt connects your app to Supabase, check if Row Level Security (RLS) is enabled:
-- Run this in Supabase SQL Editor
SELECT tablename, rowsecurity
FROM pg_tables
WHERE schemaname = 'public';
-- If rowsecurity is 'f' for any table, RLS is disabled!
Without RLS, anyone with your Supabase anon key (which is public) can read, modify, or delete all data.
-- Enable RLS
ALTER TABLE posts ENABLE ROW LEVEL SECURITY;
-- Users can only see their own posts
CREATE POLICY "Users see own posts" ON posts
FOR SELECT USING (auth.uid() = user_id);
-- Users can only modify their own posts
CREATE POLICY "Users modify own posts" ON posts
FOR ALL USING (auth.uid() = user_id);
3. Unprotected API Endpoints
Bolt generates functional endpoints, but they often lack authentication:
// Anyone can call this endpoint!
app.post('/api/admin/delete-user', async (req, res) => {
await db.deleteUser(req.body.userId);
res.json({ success: true });
});
app.post('/api/admin/delete-user', async (req, res) => {
// Check if user is authenticated
const session = await getSession(req);
if (!session) {
return res.status(401).json({ error: 'Unauthorized' });
}
// Check if user is an admin
if (session.user.role !== 'admin') {
return res.status(403).json({ error: 'Forbidden' });
}
await db.deleteUser(req.body.userId);
res.json({ success: true });
});
Security Review Process for Bolt Apps
Step 1: Secrets Audit
Search codebase for hardcoded API keys
Check all files for strings containing "key", "secret", "token"
Verify .env file exists and is in .gitignore
Move all secrets to environment variables
Step 2: Database Security
Identify which database Bolt connected
Enable RLS on all Supabase tables
Create appropriate access policies
Test that users can't access others' data
Step 3: API Endpoints
List all API routes in the project
Add authentication to protected routes
Add authorization checks (user can do this action?)
Validate all input data
Step 4: Frontend Security
No secrets in frontend code
Proper CORS configuration
User input is sanitized
External links have rel="noopener noreferrer"
Prompting Bolt for Secure Code
You can get better security from Bolt by being explicit in your prompts:
// Instead of: "Build a todo app with user accounts"
// Try:
"Build a todo app with:
- User authentication (email/password)
- Each user can only see and edit their own todos
- Use environment variables for all API keys
- Enable Row Level Security on the database
- Validate all input on the server
- Rate limit the API endpoints"
Follow-up Security Prompts
// After generating the app, ask:
"Review this code for security issues and fix:
1. Any hardcoded API keys or secrets
2. Missing authentication on API routes
3. Missing database RLS policies
4. Missing input validation
5. XSS vulnerabilities"
Bolt.new vs Other Full-Stack AI Tools
| Aspect | Bolt.new | Lovable | Replit |
|---|---|---|---|
| Full-stack generation | Yes | Yes | Yes |
| Default database | Varies (often Supabase) | Supabase | Replit DB |
| RLS auto-enabled | Not always | Not always | N/A |
| Secrets handling | May hardcode | May hardcode | Secrets panel |
| Auth included | If requested | If requested | If requested |
Exporting and Deploying Bolt Apps
When exporting your Bolt app for deployment:
- Before export: Review all code for secrets
- Create .env.example: Document required environment variables
- Set up hosting secrets: Add environment variables to your hosting platform
- Test in staging: Deploy to a test environment first
- Security scan: Run a security check before production
Does Bolt.new generate secure code?
Bolt generates functional code that often needs security hardening. Common issues include hardcoded API keys, missing database security policies, and unprotected API endpoints. Always review generated code before deploying.
Is my code stored on Bolt.new's servers?
While you're using Bolt, your code is processed on their platform. Review their privacy policy for data retention details. Export your code and store it in your own repository for long-term projects.
Can I deploy a Bolt app safely?
Yes, but you need to review and secure the code first. Check for hardcoded secrets, enable database security, add authentication where needed, and test thoroughly. Don't deploy directly without review.
What's the fastest way to secure a Bolt app?
Run a security scan, move all secrets to environment variables, enable RLS on your database, and add authentication to your API routes. These four steps address the most common vulnerabilities.