Vulnerability
Firebase

Broken Authentication in Firebase Apps

Firebase Auth provides robust authentication, but broken auth occurs when Firestore/RTDB Security Rules are too permissive, when Cloud Functions do not verify ID tokens, and when client-side auth state is trusted for authorization decisions without server verification.

Scan Your Firebase App

How Broken Authentication Manifests in Firebase

Broken auth in Firebase apps appears as: Firestore Security Rules that allow read/write to authenticated users without checking specific UIDs or roles: allow read, write: if request.auth != null. This lets any logged-in user access all data. Cloud Functions that do not verify the Firebase ID token, trusting client-sent user IDs or relying on the client-side auth state. Realtime Database rules that use .read: true or .write: true on sensitive paths. Custom claims not being checked in Security Rules, allowing regular users to access admin functionality.

Real-World Impact

A Firebase social app had Firestore rules that allowed any authenticated user to read all documents. An attacker created an account and queried the entire users collection, extracting email addresses, phone numbers, and private messages for all 100,000 users on the platform.

Step-by-Step Fix

1

Write granular Firestore Security Rules

Check document ownership and roles, not just authentication status.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // User profiles - only owner can read/write
    match /users/{userId} {
      allow read, write: if request.auth != null
        && request.auth.uid == userId;
    }
    
    // Admin-only collection
    match /admin/{document=**} {
      allow read, write: if request.auth != null
        && request.auth.token.admin == true;
    }
    
    // Posts - anyone can read, only author can 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;
    }
  }
}
2

Verify ID tokens in Cloud Functions

Always verify the Firebase ID token server-side.

import * as functions from 'firebase-functions';
import * as admin from 'firebase-admin';
admin.initializeApp();

export const adminAction = functions.https.onCall(async (data, context) => {
  // Verify auth
  if (!context.auth) {
    throw new functions.https.HttpsError(
      'unauthenticated', 'Must be logged in'
    );
  }
  
  // Verify admin role
  if (!context.auth.token.admin) {
    throw new functions.https.HttpsError(
      'permission-denied', 'Must be admin'
    );
  }
  
  // For HTTP functions, verify manually:
  // const token = req.headers.authorization?.split('Bearer ')[1];
  // const decoded = await admin.auth().verifyIdToken(token);
});
3

Set custom claims for roles

Use Firebase Admin SDK to set custom claims for role-based access.

// Set admin claim (run from Cloud Function or admin script)
await admin.auth().setCustomUserClaims(uid, { admin: true });

// In Security Rules, check the claim:
// allow write: if request.auth.token.admin == true;

// In client code, access claims after token refresh:
const idTokenResult = await user.getIdTokenResult(true);
if (idTokenResult.claims.admin) {
  // Show admin UI
}

Prevention Best Practices

1. Write granular Security Rules that check request.auth.uid against document ownership. 2. Verify ID tokens in Cloud Functions using admin.auth().verifyIdToken(). 3. Use custom claims for role-based access and check them in Security Rules. 4. Never use allow read, write: if true or if request.auth != null for sensitive data. 5. Test Security Rules using the Firebase Emulator Suite.

How to Test

1. Test Security Rules with the Firebase Emulator: firebase emulators:start 2. Try reading other users' data with an authenticated account. 3. Check if Cloud Functions verify ID tokens. 4. Search for allow read, write: if true in firestore.rules. 5. Use Vibe App Scanner to detect broken auth in your Firebase application.

Frequently Asked Questions

Is the Firebase API key a security risk?

No. Firebase API keys are designed to be public. They identify your project but do not grant access. Security is enforced by Security Rules on Firestore, RTDB, and Storage. The API key is safe to include in frontend code.

Does Firebase Auth prevent all authentication attacks?

Firebase Auth handles authentication (verifying identity) securely, but authorization (what users can access) depends on your Security Rules. Broken auth in Firebase almost always means Security Rules are too permissive, not that Firebase Auth itself is compromised.

How do I test Firebase Security Rules?

Use the Firebase Emulator Suite which includes a Rules testing framework. Write unit tests that verify rules allow/deny access for different user states. Run firebase emulators:start and use the @firebase/rules-unit-testing package.

Is Your Firebase App Vulnerable to Broken Authentication?

VAS automatically scans for broken authentication vulnerabilities in Firebase applications and provides step-by-step remediation guidance with code examples.

Scans from $5, results in minutes. Get actionable fixes tailored to your Firebase stack.