Firebase makes it fast to ship. That same speed means many developers skip configuration steps that aren't required for the app to function — but are critical for security, cost control, and reliability. This list covers the misconfigurations most commonly found in production Firebase projects in 2026, ranked roughly by impact.
Public Firestore collections (allow read, write: if true)
The most dangerous and most common. A Firestore collection or document with allow read, write: if true in its security rules is fully accessible to anyone on the internet — no authentication required. This is a legacy pattern from Firebase's early tutorials and quickstart guides that still appears in projects created from old templates.
The problem extends beyond the obvious: allow write: if true means anyone can flood your Firestore with garbage data, delete documents, or overwrite user records. Even allow read: if true exposes your entire dataset to automated scrapers.
Replace with allow read: if request.auth != null && request.auth.uid == userId; as a minimum. Run the Firebase Rules Playground with an unauthenticated access simulation to verify no collection returns true without auth. Also use our Security Rule Tester to audit all 10 common patterns.
No billing budget alerts configured
Firebase on the Blaze plan charges for every API call beyond the free tier. A single bug — a Cloud Function in an infinite loop, a Firestore listener without pagination, or bot traffic hitting an unprotected HTTP function — can generate thousands of dollars in charges within hours. Google does not automatically stop billing when a budget is exceeded; the default behavior is to continue serving traffic and charging.
Go to Google Cloud Console → Billing → Budgets & alerts. Create a budget for your Firebase project with alerts at 50%, 90%, and 100% of your expected monthly spend. Enable programmatic notifications to a Cloud Function that can disable the worst-offending APIs. This takes 10 minutes and is the single highest-ROI Firebase configuration task.
Subcollections not independently secured
Firestore security rules are not inherited by subcollections. A rule that secures /users/{uid} does not protect /users/{uid}/private/{doc}. Many developers assume parent rules cascade — they don't. Subcollections must have their own explicit match blocks.
Audit your Firestore data model for all subcollections. Add explicit match /users/{uid}/private/{doc} blocks with ownership checks for each one. Use Firebase Emulator locally to test access patterns across your full rules file.
Cloud Functions with no maximum instances configured
By default, Cloud Functions will scale to as many instances as needed to handle traffic — up to the project quota. A traffic spike, denial-of-service attack, or runaway trigger (a function that writes to Firestore, triggering another function that writes to Firestore...) can create hundreds of concurrent instances and a billing spike before you notice. The Firestore write loop is especially common: a Cloud Function triggered on Firestore writes that itself writes to Firestore creates an infinite invocation loop.
Set maxInstances: 10 (or an appropriate limit for your traffic) on every Cloud Function. This caps the billing exposure from runaway scaling. For Firestore-triggered functions, always check if the write was made by your function itself and return early to prevent loops: if (event.params.triggeredByFunction) return null;
No Firebase App Check configured
Without App Check, any client — a competitor's app, an automated scraper, a custom HTTP client — can call your Firebase backend as if it were your legitimate app. Billing abuse via unauthorized API calls, automated account creation, and credential stuffing are all easier without App Check protection.
Enable App Check in Firebase console → App Check. Use Play Integrity on Android, App Attest on iOS. Enable enforcement (not just monitoring) mode for Firestore and Cloud Functions once you've confirmed legitimate traffic is passing App Check. Takes 2–4 hours for a typical project.
Firestore indexes not optimised (missing or excessive)
Firestore's auto-indexing creates composite indexes for every field in every document. For documents with large text fields, maps, or arrays, this generates index entries that inflate storage costs by 2–5× beyond the raw document size. Conversely, missing indexes on frequently-queried fields cause query failures in production.
Review Firebase console → Firestore → Indexes. Add single-field index exemptions for large text fields, description fields, and any field you never query on. Add composite indexes for your most common query patterns. Review the Firestore storage breakdown to identify collections where index storage exceeds document storage.
FCM tokens not pruned — stale token accumulation
Every uninstalled app, factory reset, and app data clear leaves behind a dead FCM token in your database. Sending notifications to dead tokens doesn't cost extra, but it inflates your subscriber count by 20–40%, makes your delivery rate stats misleading, and wastes Cloud Function execution time processing UNREGISTERED errors from FCM's batch send response.
Store a lastSeen timestamp with every FCM token update. Run a scheduled Cloud Function monthly to delete tokens older than 90 days. Process FCM batch send responses and delete tokens that return UNREGISTERED immediately after each send.
Firebase Authentication email enumeration enabled
By default, Firebase Authentication returns a distinct error for "email not found" vs. "wrong password" — allowing an attacker to enumerate which email addresses are registered. This is a standard account privacy vulnerability known as user enumeration.
Enable "Email enumeration protection" in Firebase console → Authentication → Settings. This option returns the same error for unregistered email and wrong password, preventing enumeration. Available since Firebase SDK v10 (2023). Also enable brute-force protection under the same settings.
No Firestore read/write limits in security rules
Without write frequency limits, authenticated users can generate unlimited writes — inflating your Firestore bill and potentially denying service to other users by exhausting write quotas. This is especially problematic in collaborative features, social apps with high write rates, and any feature that writes on every user action.
Use request.time in security rules to enforce minimum intervals between writes: allow create: if request.time > resource.data.lastWrite + duration.value(1, 's');. For reads, consider using Cloud Functions as a proxy for expensive aggregation queries instead of direct Firestore reads from clients.
No monitoring or alerting on Cloud Functions errors
Cloud Functions failures are silent unless you set up alerting. A function that starts returning errors due to a schema change, an upstream API failure, or a timeout will silently fail for users until someone manually checks the Firebase console — which may not happen for days in a low-traffic app.
Set up Cloud Monitoring alerts on Cloud Functions error rate. Go to Google Cloud Console → Monitoring → Alerting → Create policy. Alert when function error rate exceeds 1% for any function. For mobile-first monitoring, the Firepulse app shows Cloud Functions error rates across all your Firebase projects in a daily push digest.
Using the Firebase Security Rule Tester
The single highest-impact action for most Firebase projects is auditing Firestore security rules. Our interactive Firebase Security Rule Tester covers misconfigurations #1, #3, and several others on this list — it takes under 5 minutes and produces a risk grade with specific fix recommendations.
Related
- Tool
Firebase Security Rule Tester
Audit 10 common Firestore and RTDB security misconfigurations interactively.
- Post
Mobile Backend Security Trends 2026
Firebase data leaks, App Check adoption, and token security in 2026.
- Tool
Cloud Functions Cost Calculator
Project your monthly Functions bill before billing surprises arrive.
- Post
Read-Only Consoles & DevOps Security
Why read-only observability tools reduce production incident blast radius.
