Skip to content
ShipSecurelySecurity reference
Menu
Your tool here — sponsor ShipSecurely

Issues

Firebase rules left open

Firestore or Storage rules that allow any read and write make the database public. The client SDK will do whatever the rules allow.

Share link · Share on X

Last updated

criticalDatabase

Shows up in: Firebase, Next.js

Markdown version

What it is

Firebase security rules are the access control for Firestore, Realtime Database, and Cloud Storage. The client SDK is not a sandbox. If the rules say yes, the client can do it, including a client someone else wrote.

The usual mistake is test mode. The Firebase console offers rules that allow reads and writes until a date, or people replace that with allow read, write: if true so the app keeps working. Both are public databases. if request.auth != null is the next mistake: any signed-in user can read every document, which is IDOR for the whole project.

Firebase App Check is an extra that tries to confirm requests come from your app. It is not a replacement for rules. A modified client can still present as a user if the rules allow that user to read everything.

The Firebase web config in your JavaScript is expected to be public. Rules are what make that safe.

How to check in 5 minutes

  1. Open Firestore rules and Storage rules in the Firebase console, and open firestore.rules and storage.rules in the repo if they exist. Search for if true and for dates that only expire access.

  2. In the rules playground, or with a second test user, read a document you do not own. If it succeeds, the rules are too open.

  3. Check that writes cannot set their own admin: true or plan: "pro". A rule that only checks request.auth != null allows that write.

  4. Confirm the rules you are reading are the ones deployed. A file in the repo can be stricter than the console, or the other way around.

How to fix

Firebase

Scope each collection to the owner, and block fields the user must not set.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /notes/{noteId} {
      allow read, update, delete: if request.auth != null
        && request.auth.uid == resource.data.userId;
      allow create: if request.auth != null
        && request.auth.uid == request.resource.data.userId;
    }
  }
}

That is a starting shape for one collection, not a full ruleset. Add rules for every collection the app uses. Collections without a match are denied by default when rules are otherwise defined. Do not add a final match /{document=**} { allow read, write: if true; } to be helpful.

Deploy with the Firebase CLI so the repo and the project match. Run the rules emulator tests if you have them. Firebase documents the rules language and the emulator in its security rules docs.

Storage needs its own file. See open storage buckets.

Next.js

If an Admin SDK service account is used on the server, rules do not apply to that SDK. Check the session in the Route Handler, the same as a Supabase secret key. Never import the service account into client code.

Supabase

This bug is the Firestore version of missing RLS. If you use Supabase instead, follow tables without row level security.

Vercel

Hosting on Vercel does not deploy Firebase rules. Deploy them with Firebase. The web app being on Vercel changes nothing about the database.

Copy-paste prompt

Paste this into Cursor, Claude Code, or whichever agent is editing the repo. Read the diff before you merge it.

You are closing open Firebase rules. Do not add features.

1. Read firestore.rules, storage.rules, and any realtime database rules. Also tell me if the repo has no rules files, because the deployed console rules may differ.
2. Remove allow read, write: if true and any time-limited test rule.
3. For each collection the app uses, require request.auth.uid to match the owner field on read, create, update, and delete.
4. Prevent clients from setting admin, role, or plan fields unless you can show an existing server-only path. If you cannot, deny those field changes.
5. Do not treat App Check as the access control.

Show the rules diff. Do not claim the console is updated unless you actually deployed.

Questions

Test mode expired and the app broke. Can I turn it back on?

That expiry is what stopped the public database. Write an owner rule instead of extending open access.

The Firebase apiKey is in the source. Do I rotate it?

The web API key is not a secret in the way a service account is. Firebase documents the client config as something your app ships. Rules are the control. Rotate a service account if that JSON leaked. Do not publish the service account to hide the apiKey.

Sources

Related