How to Add Security Rules to Firebase Studio Apps
Firebase Studio generates apps that may use default permissive Security Rules. Before going to production, you need to replace these with restrictive rules that protect your data. This guide covers the specific patterns needed for Firebase Studio applications.
Find security issues automatically before attackers do.
Follow These Steps
Check your current rules in Firebase Console
Go to Firebase Console > Firestore Database > Rules and review what is currently deployed.
// Common default rules from Firebase Studio
// These are INSECURE for production:
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write: if request.time < timestamp.date(2026, 3, 1);
}
}
}Time-based rules are test mode rules. They expire but until then give everyone full access.
Map your data model to security requirements
List each collection and determine who should have read and write access.
// Example data model mapping:
// users/{userId} -> Owner only read/write
// posts/{postId} -> Public read, author write
// comments/{commentId} -> Public read, author write/delete
// settings/{userId} -> Owner only read/write
// admin/{docId} -> Admin onlyWrite restrictive rules for each collection
Replace the default rules with collection-specific access controls.
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /users/{userId} {
allow read, write: if request.auth != null && request.auth.uid == userId;
}
match /posts/{postId} {
allow read: if request.auth != null;
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;
}
match /comments/{commentId} {
allow read: if request.auth != null;
allow create: if request.auth != null && request.resource.data.userId == request.auth.uid;
allow delete: if request.auth != null && resource.data.userId == request.auth.uid;
}
match /{document=**} {
allow read, write: if false;
}
}
}Add Storage rules
Configure rules for any file storage your Firebase Studio app uses.
rules_version = '2';
service firebase.storage {
match /b/{bucket}/o {
match /users/{userId}/{allPaths=**} {
allow read: if request.auth != null;
allow write: if request.auth != null
&& request.auth.uid == userId
&& request.resource.size < 10 * 1024 * 1024;
}
match /{allPaths=**} {
allow read, write: if false;
}
}
}Test your rules in the emulator
Use the Firebase Emulator to verify your rules work correctly.
firebase emulators:start --only firestore
# Then run your app against the emulator
# and verify all features still workDeploy the rules
Deploy your tested rules to production.
firebase deploy --only firestore:rules,storageWhat You'll Achieve
Your Firebase Studio app has production-ready Security Rules for Firestore and Storage. Each collection has appropriate access controls based on authentication and ownership.
Common Mistakes to Avoid
Mistake
Leaving time-based test rules active
Fix
Replace timestamp-based rules with proper authentication and ownership checks before the expiry date.
Mistake
Only securing top-level collections
Fix
Subcollections need their own rules. A rule on /users/{userId} does not protect /users/{userId}/settings/{settingId}.
Frequently Asked Questions
Will changing rules break my Firebase Studio app?
If the new rules are more restrictive than the current ones, some operations may fail. Test in the emulator first, then update your app code to match the new rules if needed.
How do I handle admin users in Security Rules?
Store admin status in a custom claim on the user token, then check request.auth.token.admin == true in your rules. Set custom claims via the Admin SDK in a Cloud Function.
Ready to Secure Your App?
VAS automatically scans your deployed app for the security issues covered in this guide. Get actionable results in minutes.
Start Security Scan