Firebase Security

Firebase Security Incidents

Q: What is the most common Firebase security mistake?

The most common Firebase security mistake is deploying with test rules that allow unrestricted read and write access. Firebase's default Security Rules for new projects are restrictive, but many tutorials and AI tools instruct users to set rules to 'allow read, write: if true' during development. These permissive rules are then deployed to production, giving anyone with the API key full access to the entire database. Firebase sends email warnings when it detects this pattern, but many developers ignore these notifications.

Open databases, rule misconfigurations, and real data breach examples from Firebase applications.

Millions of records have been exposed through misconfigured Firebase databases. Learn from real incidents and secure your Firebase application before it happens to you.

Scan Your Firebase App

VAS detects Firebase misconfigurations, exposed service accounts, and open databases

Firebase Exposure by the Numbers

19M+

Passwords exposed in plaintext

113 GB

Data found in open databases

4.8%

of Firebase apps misconfigured

900+

Open databases found in one study

The Firebase Security Problem

Firebase is Google's application development platform, used by millions of applications worldwide for real-time databases, authentication, cloud storage, and hosting. It powers everything from small personal projects to apps with hundreds of millions of users. Firebase's ease of use and generous free tier have made it a cornerstone of rapid application development.

However, Firebase's security model requires active configuration. Unlike a traditional backend where the server controls all data access, Firebase exposes its databases and storage directly to the client. Security Rules are the gatekeeper, and they must be explicitly written for every collection, document, and path. When these rules are missing, permissive, or incorrectly configured, the result is a database that anyone can read and write.

The scale of the problem is staggering. Multiple security research studies have found millions of user records exposed through misconfigured Firebase databases. These are not sophisticated attacks; in most cases, the data is accessible by simply appending .json to the database URL. Automated bots continuously scan the internet for open Firebase databases, and exposed data is often harvested within hours.

With the rise of vibe coding tools, the problem has intensified. AI code generators like Lovable, Cursor, and v0 frequently set Firebase Security Rules to fully permissive during development and do not configure proper rules before deployment. Developers who are new to Firebase may not understand that Security Rules are the primary security control, not the API key.

Real Data Breach Examples

19 Million Plaintext Passwords Exposed via Firebase

2024

Source: Security researchers at Appthority

Open Realtime Database (read/write: true)

Frequency: Very Common

critical

The Firebase Realtime Database configured with rules that allow all reads and writes without authentication. This is the single most common Firebase security misconfiguration. The entire database contents can be read by appending .json to the database URL.

Vulnerable Configuration

{
  "rules": {
    ".read": true,
    ".write": true
  }
}

Secure Configuration

{
  "rules": {
    ".read": false,
    ".write": false,
    "users": {
      "$uid": {
        ".read": "$uid === auth.uid",
        ".write": "$uid === auth.uid"
      }
    }
  }
}

Impact

Anyone can read the entire database by visiting project-id.firebaseio.com/.json
Anyone can write, modify, or delete any data
Data exfiltration of all stored user information
Database can be wiped by a malicious actor
Bots actively scan for this pattern

Permissive Firestore Security Rules

Frequency: Common

critical

Firestore databases with rules that allow all authenticated (or even unauthenticated) users to read and write all collections. This pattern is especially common in AI-generated code because tools set permissive rules to avoid dealing with authorization during development.

Vulnerable Configuration

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if true;
    }
  }
}

Secure Configuration

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 true;
      allow write: if request.auth != null
        && request.auth.uid == resource.data.authorId;
    }
  }
}

Impact

All Firestore collections accessible without proper authorization
Cross-user data access (any user can read any other user's data)
Data manipulation and injection by unauthorized users
Compliance violations for regulated data

Firebase Service Account Key Exposure

Frequency: Occasional

critical

Firebase service account JSON keys committed to public repositories, embedded in client-side code, or stored in accessible locations. Service account keys provide full administrative access to the Firebase project, bypassing all Security Rules.

Vulnerable Configuration

// DANGEROUS: Service account in client-side code or public repo
{
  "type": "service_account",
  "project_id": "my-project",
  "private_key_id": "abc123...",
  "private_key": "-----BEGIN RSA PRIVATE KEY-----\n...",
  "client_email": "firebase-adminsdk@my-project.iam.gserviceaccount.com"
}

Secure Configuration

// Service account should ONLY be on the server
// Store in environment variable, never in code
const admin = require('firebase-admin');
admin.initializeApp({
  credential: admin.credential.cert(
    JSON.parse(process.env.FIREBASE_SERVICE_ACCOUNT!)
  )
});
// Add to .gitignore: serviceAccountKey.json

Impact

Full administrative access to Firebase project
Can read/write all data bypassing Security Rules
Can manage user accounts (create, delete, modify)
Access to Cloud Storage and other Firebase services
Potential lateral access to linked Google Cloud resources

Open Cloud Storage Rules

Frequency: Common

high

Firebase Cloud Storage configured with rules that allow anyone to upload or download files. This leads to unauthorized access to stored files and potential abuse of storage for hosting malicious content at the project owner's expense.

Vulnerable Configuration

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

Secure Configuration

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 < 5 * 1024 * 1024
        && request.resource.contentType.matches('image/.*');
    }
  }
}

Impact

Anyone can download user-uploaded files
Attackers can upload malicious content
Storage costs can spike from unauthorized usage
Hosted malware attributed to your domain

User Enumeration via Firebase Auth

Frequency: Very Common

medium

Firebase Authentication by default returns different error messages for 'user not found' versus 'wrong password' during sign-in. This allows attackers to enumerate which email addresses have accounts. While Firebase has an Email Enumeration Protection feature, it is disabled by default in many projects.

Vulnerable Configuration

// Firebase returns different errors:
// "auth/user-not-found" → email is NOT registered
// "auth/wrong-password" → email IS registered
// This allows building a list of valid email addresses

Secure Configuration

// Enable Email Enumeration Protection in Firebase Console:
// Authentication > Settings > User actions
// Toggle "Email Enumeration Protection"

// In your code, show generic error messages:
try {
  await signInWithEmailAndPassword(auth, email, password);
} catch (error) {
  // Don't reveal whether email exists
  setError("Invalid email or password");
}

Impact

Attackers can determine which emails have accounts
Enables targeted phishing against confirmed users
Facilitates credential stuffing attacks
Privacy violation by confirming email registration

Firebase Security Checklist

Realtime Database

Rules deny all access by default
Each path has specific read/write rules
Rules validate data structure
Auth.uid used for user-scoped access
No wildcard rules in production
Test with Rules Simulator

Firestore

No match /{document=**} wildcard rules
Each collection has explicit rules
Request.auth checks on all write operations
Data validation rules for all inputs
Resource.data checks for update operations
Rate limiting where appropriate

Cloud Storage

No public read/write on user buckets
File size limits configured
Content type restrictions enforced
User-scoped folder structure
Auth checks on all operations

Authentication & Keys

Service account key not in client code or public repos
Email enumeration protection enabled
Authorized domains restricted
Password requirements configured
MFA enabled for admin accounts

How to Test Your Firebase Security

Testing your Firebase security configuration is something every developer should do before deploying to production. Here are the manual checks you can perform, followed by automated scanning options.

1. Test Realtime Database Access

Open your browser and navigate to https://YOUR-PROJECT.firebaseio.com/.json. If you see JSON data instead of a permission denied error, your database is publicly readable.

2. Use the Firebase Rules Simulator

In the Firebase Console, go to Firestore or Realtime Database and open the Rules tab. Use the Simulator to test read and write operations as different user types (unauthenticated, authenticated, admin). Verify that unauthorized operations are denied.

3. Check for Service Account Keys in Git

Search your repository for files matching serviceAccountKey.json or files containing private_key and firebase-adminsdk. Check git history for previously committed keys.

4. Scan Your Deployed Application

Use VAS to scan your deployed application URL. It automatically detects Firebase configurations, checks for exposed credentials, tests security headers, and identifies common misconfiguration patterns that manual testing might miss.

Check Your Firebase App's Security

VAS detects Firebase misconfigurations, open databases, exposed service account keys, and permissive Security Rules. Get a comprehensive report in minutes, not hours.

Get Starter Scan - $5 View Sample Report

Frequently Asked Questions

How many Firebase databases are exposed?

Research by security firms has consistently found that a significant percentage of Firebase databases are misconfigured. A 2024 study found approximately 113 gigabytes of data from 2,271 Firebase databases were publicly accessible. Earlier research estimated that 4.8% of mobile apps using Google Firebase were not properly secured, potentially exposing data from hundreds of millions of users. The number has likely grown with the rise of vibe coding, as AI tools frequently generate Firebase configurations without proper security rules.

Is my Firebase API key a security risk?

Firebase API keys are designed to be public and are not secrets. They are used to identify your Firebase project to Google's servers, not to control access to data. Security in Firebase is enforced by Security Rules for Firestore, Realtime Database, and Cloud Storage. If someone has your API key but your Security Rules are properly configured, they cannot access data they are not authorized to see. However, if your rules are permissive, the API key allows unrestricted access.

What is the most common Firebase security mistake?

The most common mistake is deploying with test rules that allow unrestricted read and write access. Firebase's default Security Rules for new projects are restrictive, but many tutorials and AI tools instruct users to set rules to 'allow read, write: if true' during development. These permissive rules are then deployed to production, giving anyone with the API key full access to the entire database.

How do I check if my Firebase database is exposed?

To check if your Firebase Realtime Database is exposed: 1) Try accessing https://YOUR-PROJECT.firebaseio.com/.json in a browser - if you see data, your database is publicly readable, 2) Check your Security Rules in the Firebase Console under Realtime Database > Rules, 3) Look for 'allow read: if true' or '.read: true' patterns, 4) For Firestore, check the Rules tab in the Firebase Console, 5) Run a security scan with VAS to automatically detect Firebase misconfigurations.

What happens if my Firebase service account key is exposed?

A Firebase service account key provides full administrative access to your Firebase project. If exposed, an attacker can: read and write all data (bypassing Security Rules), manage users (create, delete, modify accounts), access Cloud Storage files, send push notifications, and potentially access other Google Cloud services. If exposed: immediately delete the compromised key in Google Cloud Console, create a new one, audit all data for unauthorized changes, and review Cloud Logging for suspicious activity.

Related Resources

Firebase vs Supabase Security Vibe Coding Data Breaches Supabase Security Incidents Security Checklist

Last updated: February 2026