← Back to the Firebase Security Rules Exposure Checker
Pasting a Realtime Database URL into a browser tab, or reaching for curl against the Firestore REST API, is a real and fast way to confirm the single obvious case: a root or collection that returns data with no login at all. Most developers who suspect a problem reach for this first, and it genuinely works for that case. This page is not affiliated with Google or Firebase — it names the Realtime Database and Firestore REST APIs only as the manual method anyone with the project ID could already try, not a product being compared against.
| Check | By hand | This tool |
|---|---|---|
| Obvious open root | Catches it | Catches it |
| Confirming exposure without pulling real data | A plain .json request returns real data — you'd read it to prove the point | Uses shallow=true: key names only |
| Blocked path vs. genuinely empty one | Both look empty unless you read the HTTP status | Reported separately |
| Firestore's REST URL shape and document cap | Easy to get wrong or pull too much | One document per collection, correctly formed |
| Several paths/collections at once | One request at a time | All named paths in one report |
| Repeatable in CI | Manual, point-in-time | Real exit code |
If you already suspect a specific path is wide open and just want to confirm it once, requesting the URL directly is fine — it's free and you already have the project ID. The gap this tool closes is doing that safely and completely: a shallow, values-free read of the Realtime Database, a capped read of every Firestore collection you name, a clear blocked-vs-unconfirmed distinction, and an exit code the same check can gate a deploy on next time.
Appending .json to a Realtime Database URL in a browser, or requesting the Firestore REST documents endpoint with curl, is a real, fast way to confirm the single obvious case -- a root or collection that returns data with no login at all. Anyone who knows the URL shape can do this in one request.
Three ways this scripted check catches and a by-hand request easily misses. (1) A plain .json request on an open Realtime Database pulls every field value under that path, not just key names -- proving the exposure this way means already doing the thing you were checking for; the shallow=true flag most people don't know to add avoids that. (2) A response of null or an empty object looks identical whether the path is genuinely empty or the rule is correctly blocking it, unless you also read the HTTP status code -- easy to skip when eyeballing a browser tab. (3) The Firestore REST endpoint's shape (documents
A by-hand request is a point-in-time, manual look at one path or collection you remembered to try. Adding a new Firestore collection, or a rules change that is correct everywhere except the newest path, can reopen this exposure at any point after the last time someone thought to check. The CLI here returns a real exit code, so it can gate a deploy the same way a linter or test suite does -- catching the regression the day it ships rather than the next time someone happens to paste a URL into a browser.