How to check your Firebase security rules before launch

Your Firebase API key isn’t the problem. Your rules are.

Founders often panic when they spot their Firebase apiKey in their frontend code. Firebase’s own documentation says these keys are public by design: they identify your project, they don’t grant access. Your data in Cloud Firestore, Realtime Database and Cloud Storage is protected by Firebase Security Rules.

That means if your rules are open, anyone who knows your project ID can read, change or delete your data, without ever logging in. And AI tools, tutorials and Firebase’s own “test mode” all make it easy to ship open rules by accident.

(A few keys are different. Firebase service account keys, used by the Admin SDK, and AI keys like a Gemini Developer API key must stay secret. If one of those reached your frontend or a public repo, see what to do when a secret key leaks.)

Step 1: Find your rules

In the Firebase console, open each product you use and go to its Rules tab:

• Firestore Database → Rules
• Realtime Database → Rules
• Storage → Rules

If your project has a firestore.rules, database.rules.json or storage.rules file, that’s what gets deployed. Check that the file and the console match.

Step 2: Spot the rules that leave data open

These are the patterns to look for. Any of them on data that belongs to users is a problem.

Open to everyone

// Firestore or Storage
allow read, write: if true;

// Realtime Database
{ "rules": { ".read": true, ".write": true } }

Anyone on the internet can read and change everything this covers.

“Test mode” rules

allow read, write: if request.time < timestamp.date(2026, 12, 1);

Test mode opens your whole database until a date about a month away. When it expires, your app suddenly stops working, and the tempting “fix” is to push the date forward or replace it with if true. Either way, your data stays open.

Any signed-in user can see everything

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

This looks secure because it requires login, but anyone can create an account. Once they do, they can read and change every user’s data. Firebase’s documentation lists this as an insecure rule.

Trusting an email address that was never verified

allow read: if request.auth.token.email.matches('.*@yourcompany[.]com');

If you grant access by email domain, also require request.auth.token.email_verified == true. Otherwise someone can sign up with an address they don’t own.

Step 3: Lock data to its owner

For data where each document belongs to one user, rules like these limit access to the owner. Replace notes and ownerId with your collection and field:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /notes/{noteId} {
      // Only the owner can read or delete
      allow read, delete: if request.auth != null
        && request.auth.uid == resource.data.ownerId;
      // New notes must be created as yourself
      allow create: if request.auth != null
        && request.auth.uid == request.resource.data.ownerId;
      // Owners can edit, but can't hand the note to someone else
      allow update: if request.auth != null
        && request.auth.uid == resource.data.ownerId
        && request.resource.data.ownerId == resource.data.ownerId;
    }
  }
}

For Realtime Database, the equivalent keeps each user inside their own branch:

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

And for Cloud Storage, keep each user’s uploads in their own folder:

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;
    }
  }
}

Two more things worth checking: a user should never be able to make themselves an admin by editing a role or isAdmin field on their own profile, and anything that isn’t meant for clients at all can be closed with allow read, write: if false; and handled on your server.

Step 4: Test your rules safely

1. Use the Rules Playground. In the console’s Rules tab, open the Rules Playground. Simulate a read of another user’s document, first as an unauthenticated user, then as an authenticated user with a different UID. Both should be denied. Then simulate the owner reading their own document, which should be allowed.
2. Test in your app with two accounts. Sign in as User A and try to open User B’s data, for example by changing a document ID in the URL. You should get nothing.
3. Add tests before you change rules again. Firebase recommends unit testing rules with the Local Emulator Suite. Your AI tool can write these tests for you (see the prompt below).

Step 5: Turn on the extra protections

• App Check. Firebase recommends enabling App Check for every service that supports it. It helps make sure requests come from your real app, not a script. It’s a second layer, not a replacement for good rules.
• Budget alerts. Set a budget alert in your project’s billing settings, so abuse shows up as an email rather than a surprise bill.
• Keep service account keys off the client. Admin SDK credentials bypass your rules entirely. They belong only on your server or in Cloud Functions.

A fix prompt you can paste into your AI tool

Review the rules it proposes before deploying them, then re-run the Rules Playground checks in Step 4.

Review my Firebase Security Rules for Firestore, Realtime Database and
Storage. Then:
1. Replace any rule that allows access with "if true", a test-mode
   timestamp, or only "request.auth != null" on user data.
2. Lock each user's documents and files to their owner using
   request.auth.uid and an ownerId field (or the user's own path).
   Updates must not allow changing the owner. Users must not be able to
   change their own role or admin flags.
3. Close anything clients don't need with "allow read, write: if false".
4. Write Firebase Emulator unit tests proving: a logged-out user is
   denied, User A cannot read or change User B's data, and the owner
   can access their own data.
Show me the rules and tests before deploying.

The short version

• No if true or test-mode timestamp rules on user data.
• No rules where any signed-in user can read everything.
• Each user’s documents and files are locked to their own UID.
• Owners can’t reassign data or make themselves admins.
• Rules Playground: strangers and other users are denied; owners are allowed.
• App Check and a budget alert are on; service account keys stay on the server.

The Launch Check covers your Firebase rules alongside exposed keys, unprotected routes and your AI features, with fixes you can paste into your coding tool.