Firebase Security Rules Exposure Checker

Enter your Firebase project ID, plus its Realtime Database URL and/or one or more Firestore collection names. This sends real, read-only, unauthenticated requests and names which paths return real data with no login — the default-open / left-in-test-mode security rules exposure documented since Appthority's 2018 "Firebase mismanagement" report and still recurring today. Only run this against a project you own or are authorised to test.

Run the check

Firestore has no public "list every collection" endpoint the way the Realtime Database does, so name the collections your app itself reads — check your app's own source or its network tab. Leave this blank to check the Realtime Database only.

Enter a project ID and at least one of the two fields above, then click Check.

Prefer a CLI for CI, or does your browser block the Firestore check?

Same check, same modules, no browser — and never subject to browser CORS restrictions:

node check.mjs my-app-a1b2c --database-url https://my-app-a1b2c-default-rtdb.firebaseio.com --collection users --json

Get check.mjs, probe.mjs, and analyze.mjs from the repo — exit code 1 if anything is exposed, so you can gate a deploy on it. Run it after every rules change and after adding a new collection: a rule that is correct everywhere else and missing on the newest collection is the ordinary way this reopens.

Common questions

Isn't my Firebase project's config supposed to be public?

Yes — the Firebase web config object (apiKey, projectId, databaseURL, and the rest) is meant to be embedded in your client-side app, and Google's own documentation says so explicitly. It identifies your project; it does not authorise access to it. Security Rules are the only thing standing between that public config and your actual data — a database left in test mode, or hand-written with a rule like allow read, write: if true, is readable by anyone who has ever loaded your app.

What actually goes wrong here?

Both Firebase products default new projects to a 30-day "test mode" with a rule that allows any read and write with no authentication, specifically so a team can build first and lock down rules before shipping. More background: why Firebase test mode exposes your data.

Is it safe to enter my project ID and database URL into this page?

Yes — both are already public. This page never sends either of them (or anything it reads back) to our servers: the Realtime Database request goes straight from your browser to your own project's REST endpoint, the same way your app's own client already talks to it. Still, only run this against a project you own or are authorised to test.

How is this different from the Firebase console's own Rules Playground?

The Rules Playground simulates a request against your rules source and needs you to be logged in as a project member. This tool sends a real, live, unauthenticated request to your project's actual REST endpoint from the outside — the same view an attacker, an external auditor, or a developer without console access would have.

Does a clean report mean my project is secure?

No. This checks one specific, well-documented exposure — does an unauthenticated request return real data — at the Realtime Database root and at the Firestore collection names you name. It does not test authenticated roles, Cloud Storage buckets, Cloud Functions, write access, or any path/collection you did not list. Treat a clean report as evidence about what this run checked, not a full security audit.

How does this compare to just requesting the URL myself?

See how this compares to checking it by hand — the shallow, values-free read and the blocked-vs-unconfirmed distinction are easy to skip when eyeballing a raw request.