// security check

Firebase security rules check: is your Firestore open?

Short answer

If your Firebase security rules are still in test mode (`allow read, write: if true`) or expired open rules, anyone can read and overwrite your entire Firestore or Realtime Database — no login required. CodeCheck probes your Firebase project from the outside and tells you exactly which rules are open.

Check my app — free

A Firebase security rules check tells you whether your Firestore, Realtime Database, and Storage are locked down or wide open. Firebase security rules are the only access control between the public internet and your data — there's no server in between you control.

When you start a Firebase project in test mode, Google gives you rules that allow all reads and writes for 30 days. Countless AI-built apps ship with those rules never changed (or replaced with an even more permissive `if true`), which means any visitor can dump every document or wipe your database.

What open Firebase rules look like

These are the rules CodeCheck flags as critical. If your `firestore.rules` looks like this, your database is public:

DANGER — fully open Firestore rules

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

The fix: require auth and scope to the owner

Lock reads and writes to signed-in users, and scope documents to the user who owns them. Adjust the path to match your data model:

Safer Firestore rules

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId}/{document=**} {
      allow read, write: if request.auth != null
                         && request.auth.uid == userId;
    }
  }
}

Don't forget Realtime Database and Storage

Firestore, the Realtime Database, and Cloud Storage each have their own separate rules. It's common to lock one and leave another open.

Realtime Database rules live separately and default to open in test mode.
Storage rules protect user uploads — an open bucket leaks every file.
A public Firebase web API key is normal and not a vulnerability by itself; the rules are what matter.
Client-side `if` checks in your app are not security — rules run on Google's servers and are the real gate.

Firebase pre-launch checklist

No `allow read, write: if true` anywhere in your rules.
Test-mode rules replaced before the 30-day window (and before launch).
Firestore, Realtime Database, and Storage rules all reviewed separately.
Writes require request.auth != null where data is user-specific.
Rules scope documents to the owner, not just 'any signed-in user'.

Frequently asked questions

Is my Firebase database public?

It is if your security rules allow unauthenticated reads (for example test-mode rules or `allow read, write: if true`). Firebase has no server layer you control, so the rules are the entire access-control system. A CodeCheck scan tells you which of your Firestore, Realtime Database, and Storage rules are open.

Is it safe to expose the Firebase API key?

Yes. The Firebase web API key identifies your project and is meant to be in client code; it is not a secret. Your security depends entirely on your security rules, not on hiding the key.

Why does Firebase warn my rules are insecure?

Firebase emails you when your rules allow open access (such as test-mode rules that let anyone read or write). It means your data is currently reachable by the public and you should tighten the rules to require authentication and scope access to the owner.

See exactly what's exposed — in about a minute.

Paste your link. CodeCheck checks your live app the way a hacker would and hands you the fix in plain English. Free to start, no card.