Firebase security rules: examples that leak data, and rules to paste instead

How Firebase security rules work

Firebase security rules are the access rules for three products: Cloud Firestore, the Realtime Database and Cloud Storage. Each product has its own set, and every request from a browser or a mobile app is checked against them before any data moves. A request that no rule allows is denied.

They carry all the weight because everything else is public. Your app's Firebase config, API key and project ID included, ships in its JavaScript. Firebase's own security checklist says these API keys are not secret: they only identify your project, and access is decided by Security Rules, IAM and App Check. Anyone who reads your bundle can call Firestore directly, without going through your screens. The Firebase API key guide explains why hiding the key would not help.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // match: which documents this block covers
    match /notes/{noteId} {
      // allow: which operations, and the condition that must be true
      allow read, delete: if request.auth != null
                          && request.auth.uid == resource.data.ownerId;
    }
  }
}

Two rules of evaluation explain most leaks. First, allows add up: when several match blocks cover the same document, access is granted if any one of them is true, so a narrow rule can never take back what a broad one gave. Second, rules are not filters. Firestore checks a query against every document it could return and rejects the whole query if one of them would fail, instead of quietly leaving it out.

Rules judge the requests that come from your users' browsers and phones. The Firebase Admin SDK, and Cloud Functions that use it, reach your data whatever the rules say. That is why anything a client must not do belongs in server code.

Firebase rules examples that leak data

Firebase's own documentation lists most of these patterns as insecure, and they still reach production, in generated code and in leftover quick starts. Here is what each one lets a stranger do.

Open to everyone: allow read, write: if true

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

Firebase's documentation warns that with rules like these, anyone who guesses your project ID can steal, modify or delete the data, and the project ID sits in your JavaScript. allow read: if true on its own, with no write, is fine for data you would publish anyway, like a public catalogue, scoped to that one collection. On users, orders, messages or anything holding an email address, it is a leak.

Test mode: open until a date, then broken

// Test mode: open to everyone until the date
match /{document=**} {
  allow read, write: if request.time < timestamp.date(2026, 12, 7);
}

When you create a Firestore database in test mode, you start with a rule like this one: it compares the time of each request with a fixed date. Firebase's quickstart says test mode "allows anyone to read and overwrite your data", and until the date it is exactly like if true. The starter rules file in the Firebase CLI sets the date 30 days ahead; once it passes, no rule matches and every client request is denied. For the Realtime Database, Firebase documents an email alert before its test mode rules start denying all requests. Apps often ship while the date is still ahead, and when the app breaks on the day, the quickest edit is to move the date a year forward. Treat any request.time < rule that covers the whole database as open.

Signed in is not the same as allowed: request.auth != null

match /users/{userId} {
  allow read, write: if request.auth != null;   // any account, anyone's data
}

request.auth != null asks a single question: does the caller have an account? In most apps anyone can create one, and Firebase's security checklist points out that anyone could create an anonymous account in your project. So this rule means "any stranger after a sign-up", and with a wildcard on users, every user's profile. It is the database version of an IDOR vulnerability: the app shows each user their own data, while the database hands anyone everyone's.

The owner check that only reads the incoming data

// Leaks on update: the client chooses what ownerId says
allow write: if request.auth.uid == request.resource.data.ownerId;

request.resource.data is what the client sends, so the client decides what ownerId says. On a create, that is the check you want. On an update, any signed-in user can overwrite someone else's document by putting their own uid in it. Check the stored version as well: resource.data.ownerId is the owner as saved, and the caller cannot change it.

Recursive wildcards that cover more than you meant

{document=**} matches every document below it, in every subcollection. With rules_version = '2' it also matches zero segments, so match /users/{userId}/{document=**} covers the user document itself as well as everything under it. Because allows add up, a catch-all block left at the bottom of the file, often the old test mode rule, cancels every careful rule above it. Find every recursive wildcard in your rules and check what each one opens.

Firebase rules examples that hold

The fix is the same idea in every product: compare the caller's uid, or a role your server set, with the data. Start from closed and open only what the app uses.

Owner only

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

    // One profile per user, stored under their uid
    match /users/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }

    // Documents that carry their owner's uid in a field
    match /notes/{noteId} {
      allow read, delete: if request.auth != null
                          && request.auth.uid == resource.data.ownerId;
      allow create: if request.auth != null
                    && request.auth.uid == request.resource.data.ownerId;
      allow update: if request.auth != null
                    && request.auth.uid == resource.data.ownerId
                    && request.resource.data.ownerId == resource.data.ownerId;
    }
  }
}

Queries must then ask only for what the rules allow, for example where('ownerId', '==', user.uid). A query on the whole notes collection fails under these rules, because rules are not filters. When a coding agent runs into that permission error, the fix belongs in the query: loosening the rule to make the screen work reopens the leak.

Roles from custom claims

For admins, staff or paid plans, put the role in the user's token from your server with a custom claim. The client cannot change it.

// On your server, with the Admin SDK
import { getAuth } from "firebase-admin/auth";

await getAuth().setCustomUserClaims(uid, { admin: true });

match /reports/{reportId} {
  allow read, write: if request.auth != null && request.auth.token.admin == true;
}

A new claim reaches the user's ID token the next time one is issued, so the change is not instant. The claims payload is limited to 1,000 bytes: keep roles there and profile data elsewhere.

Roles from a document, and the trap that comes with it

You can also keep roles in Firestore and read them in the rule with get():

allow write: if request.auth != null
  && get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == 'admin';

This only works if users cannot edit their own role field. With the owner-only profile rule above, they can: a user updates their profile to role: 'admin', and every rule that trusts the field now trusts them. Limit the fields a user may write:

match /users/{userId} {
  allow read: if request.auth != null && request.auth.uid == userId;
  allow create: if request.auth != null && request.auth.uid == userId
                && request.resource.data.keys().hasOnly(['displayName', 'photoURL']);
  allow update: if request.auth != null && request.auth.uid == userId
                && request.resource.data.diff(resource.data).affectedKeys()
                     .hasOnly(['displayName', 'photoURL']);
}

Each get() or exists() is billed as a document read, even when the rule then rejects the request, and one request can make at most 10 of them (20 for multi-document reads, transactions and batched writes). Custom claims cost nothing per request, one more reason to prefer them for roles.

Validate what gets written

An owner check decides who writes. Validation decides what. Without it, a user can add fields your app trusts, like plan: 'pro' or credits: 99999, or store junk you pay for. Check the list of fields, their types and their sizes:

allow create: if request.auth != null
  && request.auth.uid == request.resource.data.ownerId
  && request.resource.data.keys().hasOnly(['ownerId', 'title', 'body'])
  && request.resource.data.title is string
  && request.resource.data.title.size() <= 200;

Realtime Database rules: JSON, and parents win

The Realtime Database uses JSON rules. .read and .write grant access, .validate checks the data, and keys starting with $ are wildcards. Conditions use auth (the signed-in user, or null), data (what is stored) and newData (what it would be after the write).

The trap is the cascade. A rule at a shallower path overrides the rules below it: once a parent grants read, a child cannot take it back. So ".read": true at the root opens everything, whatever the children say. .validate rules behave the other way round: they do not cascade, and every one of them must pass at every level for a write to go through.

{
  "rules": {
    ".read": true,
    "users": {
      ".read": false
    }
  }
}

{
  "rules": {
    "users": {
      "$uid": {
        ".read": "auth !== null && auth.uid === $uid",
        ".write": "auth !== null && auth.uid === $uid",
        "name": { ".validate": "newData.isString() && newData.val().length <= 100" },
        "$other": { ".validate": false }
      }
    }
  }
}

Anonymous accounts pass auth !== null here too. To tell them apart, check the provider field of auth, which is anonymous for those accounts.

Cloud Storage rules: owners, sizes and file types

Storage rules use the Firestore language, matched against file paths in the bucket. The usual leak is the same open or auth-only rule as in Firestore, matched on {allPaths=**} instead of {document=**}, which serves every upload, ID scans and invoices included, to whoever asks. The usual fix keys each folder by its owner's uid and limits what can be uploaded:

rules_version = '2';
service firebase.storage {
  match /b/{bucket}/o {
    // Files look like: user/<uid>/<file>
    match /user/{userId}/{fileName} {
      allow read, delete: if request.auth != null && request.auth.uid == userId;
      allow create, update: if request.auth != null && request.auth.uid == userId
                            && request.resource.size < 5 * 1024 * 1024
                            && request.resource.contentType.matches('image/.*');
    }
  }
}

Reads split in two here as well: get downloads one file and list lists a folder, and list only exists with rules_version = '2'. A public allow read covers both, so anyone can list a folder of user uploads and download each file. Without the size and type checks, a user can upload gigabytes you pay to store, or a file that is not the image your app expects.

How to test Firebase security rules before you deploy

1. 1

   Read what is actually deployed

   In the Firebase console, open Firestore, Realtime Database or Storage and click the Rules tab: it shows the version that is live. If the project also has a rules file in the repository, edit in one place only: firebase deploy --only firestore:rules (or database, or storage) from an old file overwrites a fix made in the console.

2. 2

   Try requests in the Rules Playground

   From the Rules tab, open Rules playground. Pick a read or a write, a document path, and who is asking: unauthenticated, an anonymous user, or a specific user ID. Run it as a visitor with no account, then as a user who does not own the document. Both should be denied.

3. 3

   Write unit tests against the emulator

   The Firebase emulator runs your rules locally, and the @firebase/rules-unit-testing package lets a test act as any user and assert that a request fails. If firebase.json names no rules file and the test loads none, the emulator treats the project as open, so point it at yours.

4. 4

   Run them on every change

   Cover the three callers that matter: a visitor with no account, the owner and another user. Run the tests before each deploy, and whenever a coding agent touched the rules.

import { readFileSync } from "node:fs";
import { initializeTestEnvironment, assertFails, assertSucceeds } from "@firebase/rules-unit-testing";

const env = await initializeTestEnvironment({
  projectId: "demo-rules-test",
  firestore: { rules: readFileSync("firestore.rules", "utf8") },
});

const alice = env.authenticatedContext("alice").firestore();
const bob = env.authenticatedContext("bob").firestore();
const visitor = env.unauthenticatedContext().firestore();

await assertSucceeds(alice.doc("users/alice").get());   // the owner
await assertFails(bob.doc("users/alice").get());        // another user
await assertFails(visitor.doc("users/alice").get());    // no account

await env.cleanup();

Traps people miss after the first fix

• A leftover catch-all. Fixing the rules for users changes nothing while a catch-all recursive wildcard further down still lets everyone in. Allows add up.
• One product fixed, two left open. Firestore, the Realtime Database and Storage each have their own rules. A project that started all three in test mode needs three fixes.
• A profile that holds its own role. If users can write their whole profile document, every field your rules or your app trust, like role, isAdmin or plan, is theirs to set. Limit writable fields with affectedKeys().hasOnly(), or move roles to custom claims.
• Email domain checks without verification. request.auth.token.email.matches('.*@yourcompany[.]com') passes for anyone who signs up with that address before verifying it. Add request.auth.token.email_verified == true.
• App Check taken for access control. App Check helps make sure requests come from your app. Which user may read which document is still up to the rules.

What Keybrum tests on a live Firebase app

Rules on paper show what you meant. An attack shows what a stranger gets. On an app whose owner proved ownership, Keybrum reads the Firebase config from the JavaScript, takes the collection names the code uses (or common ones like users, orders and messages when the code names none), and then:

• reads each Firestore collection with no account, then again as a brand-new account it signs up itself;
• tries a write with a probe that can never create a document: rules are checked first, so the answer shows whether the write would have been allowed, and nothing is stored;
• reads the root of the Realtime Database;
• lists the Storage bucket and flags the files that look sensitive;
• looks for API keys and other secrets saved inside the documents it could read.

The Firebase security guide covers the rest of a Firebase app beyond the rules, and the checklist for apps built with AI puts them next to everything else to check before launch.