FirebaseJanuary 5, 202612 min read

Firebase Security Guide: Protect Your Firestore Data

Firebase makes backend development easy, but easy doesn't mean secure by default. This guide covers everything you need to protect your Firebase app from data exposure and unauthorized access.

What You'll Learn

  1. Understanding Firebase's security model
  2. Writing secure Firestore rules
  3. Common security rule patterns
  4. Firebase Auth security
  5. Storage bucket protection
  6. Testing your security rules

Understanding Firebase Security

Firebase uses a different security model than traditional backends. Your API key is designed to be public—it's not a secret. Security is enforced through Firestore Security Rules and Firebase Auth.

This is Public (and OK)

apiKey: "AIzaSyC..."

The Firebase API key identifies your project. It's not a secret—security comes from your rules.

This is a Secret (Never Expose)

Service account JSON files and Admin SDK credentials should never be in client-side code.

Writing Secure Firestore Rules

Firestore Security Rules control who can read and write data. Without proper rules, anyone can access your entire database.

The Dangerous Default

// NEVER use this in production!

rules_version = '2';

service cloud.firestore {

match /databases/{database}/documents {

match /{document=**} {

allow read, write: if true;

}

}

}

Secure Pattern: User-Owned Data

// Users can only access their own documents

rules_version = '2';

service cloud.firestore {

match /databases/{database}/documents {

match /users/{userId} {

allow read, write: if request.auth != null

&& request.auth.uid == userId;

}

}

}

Pattern: Public Read, Authenticated Write

// Blog posts: anyone reads, authors 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;

}

Pattern: Data Validation

// Validate data on write

match /profiles/{userId} {

allow read: if request.auth.uid == userId;

allow write: if request.auth.uid == userId

&& request.resource.data.keys().hasAll(['name', 'email'])

&& request.resource.data.name is string

&& request.resource.data.name.size() < 100;

}

Firebase Auth Security

Firebase Auth is secure by default, but there are configuration options you should review:

  • Enable email verification – Prevent fake accounts
  • Set password requirements – Enforce minimum length
  • Configure authorized domains – Only allow your domains
  • Enable email enumeration protection – Hide which emails exist

Testing Your Security Rules

Always test your rules before deploying. Firebase provides tools for this:

  1. 1
    Use the Rules Playground in Firebase Console
  2. 2
    Write unit tests with the Firebase Emulator
  3. 3
    Test as unauthenticated user in incognito mode
  4. 4
    Use VAS to automatically test for data exposure

Firebase Security Checklist

Security rules deny all by default
Rules use request.auth for authentication
Data validation in security rules
No service account keys in client code
Email verification enabled
Authorized domains configured
Storage bucket rules configured
Rules tested in emulator
VAS scan completed

Test Your Firebase Security

VAS automatically tests your Firebase app for exposed data, insecure rules, and common vulnerabilities.

Related Articles