To secure a Bolt.new + Firebase stack, you need to: (1) replace test-mode Firestore rules with production-ready rules that verify authentication, (2) configure Storage rules if your app uploads files, (3) set up authorized domains in Firebase Auth settings, and (4) verify auth state handling persists sessions correctly. This blueprint provides platform-specific guidance for post-export security hardening.
TL;DR
Bolt.new generates Firebase apps with test-mode security rules that allow anyone to read and write all data. Before deploying: replace test rules with proper Firestore and Storage rules, configure Firebase Auth domains, and verify no service account keys are exposed. Test your rules with the Firebase Emulator before going live.
The Bolt.new + Firebase Security Problem
Bolt generates apps that work with Firebase's test mode:
| What Bolt Generates | Security Risk |
|---|---|
| Firebase initialization code | Usually correct, config is safe to expose |
| Firestore queries | Assume permissive rules, no auth checks |
| Auth integration | May not persist sessions properly |
| Security rules | Often test mode or missing entirely |
Part 1: Replace Firebase Test Mode Rules
Check Current Rules
In Firebase Console, check your Firestore rules:
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write: if true; // World-writable!
}
}
}
Apply Secure Rules
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
// Users collection - only own document
match /users/{userId} {
allow read, update, delete: if request.auth != null
&& request.auth.uid == userId;
allow create: if request.auth != null;
}
// Posts - public read, owner write
match /posts/{postId} {
allow read: if true;
allow create: if request.auth != null
&& request.resource.data.authorId == request.auth.uid;
allow update, delete: if request.auth != null
&& resource.data.authorId == request.auth.uid;
}
// Private user data
match /private/{userId}/{document=**} {
allow read, write: if request.auth != null
&& request.auth.uid == userId;
}
// Deny everything else
match /{document=**} {
allow read, write: if false;
}
}
}
Deploy rules before your app: Firestore rules changes take effect immediately. Deploy secure rules before making your app public.
Part 2: Firebase Storage Rules
If your Bolt app uses Firebase Storage, secure it too:
rules_version = '2';
service firebase.storage {
match /b/{bucket}/o {
// User uploads - restricted to own folder
match /users/{userId}/{allPaths=**} {
allow read: if request.auth != null;
allow write: if request.auth != null
&& request.auth.uid == userId
&& request.resource.size < 5 * 1024 * 1024 // 5MB limit
&& request.resource.contentType.matches('image/.*');
}
// Public assets (admin-uploaded only)
match /public/{allPaths=**} {
allow read: if true;
allow write: if false; // Only via Admin SDK
}
}
}
Part 3: Authentication Setup
Configure Auth Domains
In Firebase Console → Authentication → Settings:
# Add your production domains:
yourdomain.com
www.yourdomain.com
yourdomain.vercel.app # If using Vercel
# Remove or limit localhost for production
Verify Auth State Handling
import { useEffect, useState } from 'react';
import { onAuthStateChanged, User } from 'firebase/auth';
import { auth } from '../lib/firebase';
export function useAuth() {
const [user, setUser] = useState<User | null>(null);
const [loading, setLoading] = useState(true);
useEffect(() => {
// This listener handles auth state persistence
const unsubscribe = onAuthStateChanged(auth, (user) => {
setUser(user);
setLoading(false);
});
return () => unsubscribe();
}, []);
return { user, loading };
}
// Usage: Protect routes by checking loading and user
// if (loading) return
// if (!user) return
Part 4: Verify Generated Code
Search for Security Issues
# Look for service account keys (should never be in client code)
grep -r "private_key" .
grep -r "service_account" .
# Check for hardcoded Firebase config (usually fine, but verify)
grep -r "apiKey" . --include="*.ts" --include="*.js"
# Find Firestore queries to review
grep -r "collection\|doc\|setDoc\|updateDoc" . --include="*.ts"
Security Checklist
Post-Export Checklist for Bolt + Firebase
Firestore rules replaced from test mode
Storage rules configured (if using)
Auth domains configured for production
No service account keys in code
Auth state listener implemented
Protected routes check auth state
Rules tested in Firebase Emulator
Query patterns match rule structure
Alternative Stacks to Consider
**Bolt.new + Supabase**
PostgreSQL alternative with built-in RLS
**Bolt.new + React + Firebase**
React-specific Firebase patterns
**Bolt.new + Convex**
Real-time alternative with TypeScript functions
My Bolt app stopped working after adding rules. Why?
Bolt-generated queries assume permissive access. Your new rules may block queries that don't match the expected patterns. Check that queries include proper auth context and match your rule structure.
Is the Firebase apiKey safe to expose?
Yes, the client-side Firebase config (apiKey, authDomain, etc.) is designed for public exposure. Security comes from your Firestore and Storage rules, not from hiding these values.
How do I test rules before deploying?
Use the Firebase Emulator Suite locally or the Rules Playground in Firebase Console. Test authenticated access, unauthenticated access, and cross-user access attempts.