Firebase Security Checklist: Protect Your AI-Built App
Complete Firebase security guide. Fix open Firestore rules, secure Cloud Functions, rotate leaked keys, and lock down Storage buckets.
By Gabriel CA · Kraftwire Software
· 9 min readKey Takeaway
Firebase provides powerful backend services, but its default security rules are wide open. This checklist covers the most critical Firebase security settings you need to configure before launching your app.
Why Firebase Security Matters
Firebase is one of the most popular backend-as-a-service platforms. It handles authentication, databases (Firestore and Realtime Database), storage, and hosting. Millions of apps rely on it.
But Firebase ships with permissive defaults. The Realtime Database starts in test mode with read and write access open to everyone. Firestore test mode expires after 30 days, but many developers forget to update their rules before that deadline. Storage buckets often allow unrestricted uploads.
These defaults make development easy, but they also make your app a target. Automated scanners constantly look for Firebase projects with open security rules. If yours are open, attackers will find them.
Firestore Security Rules
Firestore security rules control who can read and write data in your database. Every collection and document needs explicit rules.
The Most Dangerous Rule
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write: if true;
}
}
}
This allows anyone to read and write any document in your entire database. If your Firestore rules look like this in production, you have a critical vulnerability.
How to Fix It
Write rules that match your data access patterns. Users should only access their own data unless you explicitly need shared access.
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /users/{userId} {
allow read, update: if request.auth != null && request.auth.uid == userId;
allow create: if request.auth != null;
}
match /posts/{postId} {
allow read: if true;
allow create: if request.auth != null;
allow update, delete: if request.auth != null && request.auth.uid == resource.data.authorId;
}
}
}
Rule Writing Best Practices
Start with deny-all and add specific allows
Always check request.auth for authenticated endpoints
Validate data shapes using request.resource.data
Test rules using the Firebase Emulator Suite
Never use recursive wildcards with allow-all permissions
Realtime Database Rules
The Realtime Database uses a JSON-based rules system that is different from Firestore rules but has the same risks.
Dangerous Default
{
"rules": {
".read": true,
".write": true
}
}
Secure Pattern
{
"rules": {
"users": {
"$uid": {
".read": "$uid === auth.uid",
".write": "$uid === auth.uid"
}
},
"publicPosts": {
".read": true,
"$postId": {
".write": "auth !== null && newData.child('authorId').val() === auth.uid"
}
}
}
}
Firebase Storage Rules
Storage rules control who can upload and download files. Open storage rules let attackers upload malicious files or fill your storage quota.
What to Check
Are uploads restricted to authenticated users?
Do you validate file size limits?
Do you restrict file types?
Are user-uploaded files isolated to user-specific paths?
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 < 5 * 1024 * 1024
&& request.resource.contentType.matches('image/.*');
}
}
}
Advanced Storage Protections
Beyond basic rules, consider these additional storage security measures:
Implement server-side virus scanning for uploaded files. Firebase Storage triggers can invoke Cloud Functions that scan files using services like VirusTotal or ClamAV before making them accessible to other users.
Set up lifecycle rules to automatically delete temporary files. If your app creates preview images or processing artifacts, configure automatic cleanup to reduce your attack surface and storage costs.
Use signed URLs for sensitive downloads instead of making files publicly readable. Signed URLs expire after a set time and can be restricted to specific users or IP ranges.
Authentication Configuration
Firebase Authentication supports multiple providers (email, Google, GitHub, etc.). Each needs proper configuration.
What to Check
Is email verification required before granting access?
Are unused authentication providers disabled?
Is the authorized domains list restricted to your actual domains?
Are password requirements configured (minimum length)?
Authorized Domains
Firebase allows authentication from any domain by default during development. In production, restrict this to your actual domains. Go to Firebase Console, then Authentication, then Settings, then Authorized Domains.
Remove localhost and any test domains before going live. If an attacker sets up a phishing page on their own domain and your Firebase project accepts authentication from any domain, they can harvest credentials that work against your real application.
Multi-Factor Authentication
For applications that handle sensitive data, enable multi-factor authentication. Firebase supports SMS-based and TOTP-based MFA. While SMS has known weaknesses (SIM swapping attacks), it is still significantly better than password-only authentication.
Consider requiring MFA for admin users and offering it as optional for regular users. This balances security with usability.
Cloud Functions Security
If you use Firebase Cloud Functions, they need their own security review.
What to Check
Are HTTP functions protected with authentication checks?
Do functions validate input data?
Are function permissions scoped to minimum required access?
Is sensitive data logged anywhere it should not be?
// Always verify authentication in Cloud Functions
export const sensitiveOperation = onCall(async (request) => {
if (!request.auth) {
throw new HttpsError("unauthenticated", "Must be logged in");
}
// Verify the user has permission
const userDoc = await admin.firestore()
.collection("users")
.doc(request.auth.uid)
.get();
if (!userDoc.exists || userDoc.data()?.role !== "admin") {
throw new HttpsError("permission-denied", "Admin access required");
}
// Process the request
});
Function Environment Variables
Store all secret keys in Firebase environment configuration, not in your function code. Use the Firebase CLI to set these values:
firebase functions:config:set stripe.secret="sk_live_..." openai.key="sk-..."
Access them in your functions with functions.config(). Never hardcode secrets, even in server-side code, because your source repository might become public or be accessed by people who should not see production keys.
API Key Restrictions
Firebase projects come with API keys that are embedded in your frontend configuration. While these keys are designed to be public, you should still restrict them.
Google Cloud Console Restrictions
Restrict by HTTP referrer (your production domains only)
Restrict by API (only enable the APIs your app uses)
Create separate keys for development and production
Monitoring API Usage
Set up billing alerts and API usage quotas. An unrestricted API key used in a denial-of-service attack could generate significant charges on your Google Cloud account.
Security Monitoring and Alerts
Do not wait for users to report problems. Set up proactive monitoring.
Firebase App Check
App Check verifies that requests to your backend come from your legitimate app, not from scripts or modified clients. Enable App Check for Firestore, Realtime Database, Storage, and Cloud Functions.
Audit Logging
Enable audit logs to track who accesses your data and when. This is essential for compliance requirements and for investigating security incidents after they happen.
Alerting Rules
Set up alerts for unusual patterns: sudden spikes in authentication failures, unexpected data access volumes, or requests from unusual geographic locations. Google Cloud Monitoring can trigger notifications via email, SMS, or webhook when these patterns appear.
The Complete Checklist
Before launching any Firebase application, verify each item:
Firestore rules deny all access by default and grant specific permissions
Realtime Database rules follow the same principle
Storage rules restrict uploads by user, file type, and size
Email verification is required for new accounts
Authorized domains are restricted to production URLs
Unused auth providers are disabled
Cloud Functions verify authentication on every request
API keys are restricted by referrer and API scope
App Check is enabled for all backend services
Billing alerts and API quotas are configured
Audit logging is active
Test mode rules have been replaced with production rules
The Bottom Line
Firebase is a powerful platform, but power without proper configuration is a liability. Every item on this checklist represents a real vulnerability that attackers actively exploit. Spend an hour going through your Firebase security settings today. It is far less painful than dealing with a data breach tomorrow.
Firebase Security Testing Tools
Before launching, use these tools to validate your security configuration.
Firebase Emulator Suite
The Firebase Emulator Suite lets you test security rules locally without affecting production data. Write unit tests for your rules that cover both allowed and denied access patterns. Test edge cases like expired tokens, missing fields, and cross-user access attempts.
Rules Playground
The Firebase Console includes a Rules Playground that lets you simulate requests against your security rules. Use it to verify that specific users can or cannot access specific documents. Test every role in your application to make sure permissions work as expected.
Third-Party Scanning
Run an automated security scan against your deployed application to catch issues that rule testing alone might miss. Scanners check for exposed configuration, open endpoints, and misconfigured headers that exist outside the Firebase rules system.
Staying Current with Firebase Security
Firebase evolves constantly. New features bring new security considerations, and old defaults sometimes change. Subscribe to the Firebase blog and release notes to stay informed about security updates. Join the Firebase community on Discord or Stack Overflow where security issues are discussed openly. When Google announces a new Firebase feature, read the security documentation before enabling it in production. Proactive awareness is always cheaper than reactive incident response.