← Back to Blog

Firebase Security · 9 min read · June 22, 2026

How to Secure a Firebase App for Production in 2026

Firebase is powerful out of the box, but 'secure by default' it is not. The settings that make development fast — wide-open security rules, undisabled email enumeration, no App Check — will get your production app compromised. Here is exactly how to lock it down.

1. Lock Down Firestore Security Rules

This is the single most important step. Firebase's default test mode — allow read, write: if true — allows anyone on the internet to read and write your entire database. This must be the first thing you change.

The Production Firestore Rule Template

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {

    // Deny all by default
    match /{document=**} {
      allow read, write: if false;
    }

    // User profiles — only the owner can read/write their own
    match /users/{userId} {
      allow read: if request.auth != null && request.auth.uid == userId;
      allow write: if request.auth != null && request.auth.uid == userId
        && request.resource.data.keys().hasAll(['name', 'email']);
    }

    // Team documents — authenticated users in the team can read
    match /teams/{teamId} {
      allow read: if request.auth != null
        && request.auth.token.teamId == teamId;
      allow write: if request.auth != null
        && request.auth.token.role == 'admin';
    }

    // Public content — anyone can read, but only admins can write
    match /public/{document} {
      allow read: if true;
      allow write: if request.auth != null
        && request.auth.token.role == 'admin';
    }
  }
}

Key principles in these rules:

• Deny-first: Start with allow: if false for all documents, then open up only what is needed.
• Authenticated access: Always check request.auth != null before allowing writes.
• Data validation: Use request.resource.data to verify the shape and content of incoming writes.
• Role-based gates: Reference request.auth.token to check custom claims.

Testing Your Rules

Use the Firebase Emulator Suite to test rules locally before deploying:

# Install the Firebase CLI
npm install -g firebase-tools

# Start the emulators
firebase init emulators
firebase emulators:start

# Run security rules tests
firebase emulators:exec --only firestore 'npm test'

2. Enable Firebase App Check

Firebase App Check prevents attackers from calling your Firebase APIs using stolen API keys. Even with perfect security rules, if an attacker gets your project's API key (which is embedded in your client app), they can attempt to brute-force auth endpoints or abuse backend services.

App Check verifies that requests come from your genuine app using platform attestation. For web apps, this means reCAPTCHA Enterprise:

// Web: Initialize App Check
import { initializeAppCheck, ReCaptchaEnterpriseProvider } from 'firebase/app-check';

const appCheck = initializeAppCheck(app, {
  provider: new ReCaptchaEnterpriseProvider('your-site-key'),
  isTokenAutoRefreshEnabled: true
});

// Enforce App Check in Security Rules
// In Firestore rules:
// allow read: if request.auth != null && request.token.app_check.token_ttl_seconds > 0;

After enabling App Check, go to the Firebase Console and enforce it for Cloud Firestore, Cloud Storage, and Cloud Functions. Without enforcement, App Check is passive — it logs but does not block.

3. Harden Firebase Authentication

Authentication is your first line of defense. Here is how to lock it down in 2026.

Disable Email Enumeration

By default, Firebase Auth tells you whether an email address is registered when someone tries to sign in or create an account. Attackers use this to harvest valid emails. Disable it in the Firebase Console under Authentication > Settings > User Account Linking.

Use Custom Claims for Role-Based Access

// Admin SDK: Set custom claims (server-side only)
const admin = require('firebase-admin');

await admin.auth().setCustomUserClaims(uid, {
  role: 'admin',
  teamId: 'team-abc-123',
  tier: 'premium'
});

// Then enforce in security rules:
// match /admin/{document} {
//   allow read: if request.auth != null
//     && request.auth.token.role == 'admin';
// }

Never set custom claims from a client. Always use a trusted server environment like Cloud Functions or your own backend.

Enable Multi-Factor Authentication (MFA)

Firebase supports SMS-based MFA. Enable it for all production users, and make it mandatory for admin accounts. In the Firebase Console, go to Authentication > Sign-in methods > Multi-factor authentication.

Restrict Sign-In Methods

Disable any sign-in providers you do not use. Anonymous auth in particular is often left enabled accidentally and can be abused.

4. Protect Firebase Storage

Cloud Storage security rules follow the same pattern as Firestore. Never leave them open:

rules_version = '2';
service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write: if false;
    }

    // User uploads — only the owner can read/write their own files
    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  // 10MB limit
        && request.resource.contentType.matches('image/.*');
    }

    // Public assets — anyone can read
    match /public/{allPaths=**} {
      allow read: if true;
      allow write: if request.auth != null
        && request.auth.token.role == 'admin';
    }
  }
}

5. Separate Development and Production Environments

One of the most common Firebase security mistakes is developing against your production project. Every developer with access to the Firebase Console is one misclick away from modifying production data or deploying test rules to production.

Set Up Multiple Firebase Projects

Create separate projects for development, staging, and production. Use the Firebase CLI's project aliases to switch between them safely:

# Set up project aliases
firebase use --add

# List projects
firebase use --list

# Switch between environments
firebase use development
firebase deploy --only firestore:rules

firebase use production
firebase deploy --only firestore:rules

Use a .firebaserc file to define your aliases:

{
  "projects": {
    "default": "myapp-dev",
    "development": "myapp-dev",
    "staging": "myapp-staging",
    "production": "myapp-prod"
  }
}

Development projects should use test mode rules and emulators. Production projects should use locked-down rules and require MFA for Console access.

6. Monitor Firebase Security Continuously

Security is not a one-time configuration. You need continuous monitoring to detect misconfigurations, unusual traffic patterns, and attempted breaches.

Enable Firebase Security Rules Monitoring

In the Firebase Console, go to Firestore > Rules > Monitoring to see denied-request metrics. A sudden spike in denied requests usually means an attacker is probing your rules.

Set Up Cloud Monitoring Alerts

# Example: Create a Cloud Monitoring alert for Firestore denied requests
# This uses gcloud — configure it in the Cloud Console UI or via API

# Alert on > 100 denied requests per minute over 5 minutes
# Condition: metric.type = "firestore.googleapis.com/rule/denied_count"
# Threshold: 100, Duration: 5m

Audit Authentication Activity

Monitor Firebase Auth activity through Cloud Logging. Look for:

• High volumes of failed sign-in attempts (brute-force indicator)
• Suspicious sign-in locations far from your user base
• New provider-linked accounts created in bulk

7. Additional Production Safety Checks

Here is a quick checklist to run before your next deployment:

• Firestore rules are in locked or custom mode — not test mode.
• App Check is enabled and enforced on all services.
• Email enumeration is disabled in Auth settings.
• Anonymous auth is disabled if not needed.
• MFA is enabled for admin accounts.
• API key is restricted in Google Cloud Console to allowed HTTP referrers and APIs.
• Firebase CLI is not logged in with a production-service-account on development machines.
• Cloud Functions validate auth context and do not trust client-supplied UIDs.
• Environment separation — dev, staging, and prod are different projects.
• Billing alerts are set up to catch runaway costs from abuse.

The Bottom Line

Firebase is not inherently insecure — but it is designed for productivity, not production security. The defaults that get you to MVP fast will get you compromised if you ship them to production. Security rules, App Check, authentication hardening, environment separation, and continuous monitoring are not optional; they are the minimum viable security posture for any Firebase app serving real users in 2026.

The projects that get breached are almost never the ones with sophisticated threats targeting them. They are the ones with test-mode rules, no App Check, and a developer who assumed "Google handles security." Google handles infrastructure security. You handle your app's security. Do not skip the lock-down step.