Firebase security rules check: audit and fix before launch

You need owner or editor access to your own Firebase project, the Firebase CLI installed and logged in, and your rules files in the repository. If your rules only exist in the console today, copy them into files first so they are versioned. Only test projects you own.

At the end you will have deny-by-default rules for every Firebase product you use, user-scoped access on each collection, tests that fail if the rules become open, and a live check from outside your app.

The apiKey and project identifiers in your Firebase web config are not secrets. They identify your project so the client libraries know where to send requests. Rules decide what a request can do, so hiding the config gives no protection, and open rules cannot be fixed by hiding it.

Firebase also documents App Check, which verifies that requests come from your genuine app. It protects you from abuse by other clients, and it complements rules rather than replacing them. It says itself that it prevents some but not all abuse vectors, so rules stay the primary control.

Firebase Security Rules are defined separately for each product. Firestore and Cloud Storage use one rule language, and Realtime Database uses JSON. Rules across products do not share protection, so open the console and read each one you use: Firestore Database > Rules, Storage > Rules, and Realtime Database > Rules.

Pull the current versions into your repository so you can review them as files. The CLI writes them to the paths named in firebase.json when you run firebase init, and you can copy the console text in by hand if that is quicker.

Look for these patterns. They allow access to everyone, or to everyone until a date passes, at which point the app breaks and a panicked fix often makes it open again. Firebase's documentation warns against rules that allow anyone to overwrite the entire database.

In Realtime Database rules, a top-level .read or .write set to true has the same effect. Realtime Database rules cascade, so a permissive rule at a shallow path grants access to everything beneath it even if a deeper rule says false.

match /{document=**} {
  allow read, write: if true;
}

match /{document=**} {
  allow read, write: if request.time < timestamp.date(2026, 10, 1);
}

Start from deny-all. In Firestore, anything not matched by an allow rule is refused, so you only write what each collection needs. Rules are applied as OR statements, so if any matching rule grants access, the request succeeds. That means a broad rule anywhere can undo your careful ones.

The example lets a signed-in user manage their own profile document and read, create, update and delete only orders that carry their own uid. On create, it checks the incoming data, so a user cannot write an order that claims another owner. On update, it checks both the stored document and the new version so the owner field cannot be changed.

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 /orders/{orderId} {
      allow read, delete: if request.auth != null && resource.data.uid == request.auth.uid;
      allow create: if request.auth != null && request.resource.data.uid == request.auth.uid;
      allow update: if request.auth != null
        && resource.data.uid == request.auth.uid
        && request.resource.data.uid == request.auth.uid;
    }
  }
}

Apply the same idea to the other products. For Storage, scope files by a path segment that holds the user id, and check it against request.auth.uid. For Realtime Database, use auth.uid in a per-user path. Firebase's database documentation shows this pattern with a write rule that compares the path variable to auth.uid.

rules_version = '2';
service firebase.storage {
  match /b/{bucket}/o {
    match /users/{userId}/{allPaths=**} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

{
  "rules": {
    "users": {
      "$uid": {
        ".read": "auth != null && auth.uid === $uid",
        ".write": "auth != null && auth.uid === $uid"
      }
    }
  }
}

Firebase provides two ways to test: the Rules Playground in the console for a quick check, and the Local Emulator Suite for repeatable tests you keep in the repository. Use both. In the Playground, simulate a signed-out read, then an authenticated read as a user who does not own the document. Both should be denied, and the owner's read should be allowed.

For a repeatable version, start the emulator and run rule tests against it. The Firebase docs describe unit testing rules against the emulator, and the test cases are the part worth keeping: one that a signed-out request is refused, one that another user is refused, and one that the owner is allowed.

npm install --save-dev firebase-tools @firebase/rules-unit-testing
firebase emulators:start --only firestore

Deploy only the rules, not the whole project, so a mistaken hosting change does not ride along. Firebase notes that rule changes can take up to 10 minutes to reach active listeners, so wait before the final check.

Then test from outside your app. Firestore exposes a REST endpoint per project, and a signed-out request to it should be refused for any private collection. A permission denied response is the pass condition. A JSON document in the body means your live rules are open.

firebase deploy --only firestore:rules,storage

curl -s "https://firestore.googleapis.com/v1/projects/<project-id>/databases/(default)/documents/orders?pageSize=1"
curl -s "https://<database-name>.firebaseio.com/users.json"

• Checking only request.auth != null. That lets any signed-in user, including one who just signed up, read everyone's documents.
• Fixing Firestore and forgetting Storage or Realtime Database, which have separate rule sets.
• Leaving a date-based test-mode rule in place until the app breaks, then extending the date instead of writing real rules.
• Trusting a role or owner field that the client wrote itself. Compare against request.auth.uid or a claim the server set.
• Assuming rules protect server-side code. Firebase's server client libraries bypass rules and rely on IAM instead, so your server must check ownership itself.
• Expecting a rule at a deeper Realtime Database path to override a permissive rule above it. Rules there cascade downward and cannot be revoked lower down.

Run the emulator rule tests in CI so a loosened rule fails the build. Re-read your rules whenever you add a collection, storage path or database node, and whenever an AI tool edits the rules file. Deploy rules from the repository rather than pasting into the console, so the file you reviewed is the file that is live. Consider App Check once rules are correct, as an extra layer against clients that are not your app.