← Firebase security rules exposure checker
Both Firebase products -- the Realtime Database and Firestore -- let you start a new project in test mode: a security rule that reads, in effect, "allow any read and write, no authentication required," so a team can build against real data before writing real rules. Firebase's own console warns that test mode expires after 30 days and reverts to fully closed -- but the warning is easy to miss, easy to dismiss, and easy to work around by simply extending the rule by hand once it expires, which converts a temporary convenience into a permanent, silent exposure.
Firebase's client config -- apiKey, projectId, databaseURL,
and the rest -- is meant to be public; it identifies your project the same way a URL does, not a
credential. The only thing standing between that public config and your actual data is
the Security Rules attached to the Realtime Database and to Firestore. With a rule that allows
read (and often write) to anyone, a plain unauthenticated GET to
<databaseURL>/.json or to a Firestore collection's REST endpoint returns real
data -- not a subset scoped to "your own" anything, to any visitor, including one who never
logged in.
Appthority's 2018 research, one of the first large-scale looks at this exposure class, found more than 2,300 mobile apps leaving a Firebase backend open this way, exposing tens of millions of records including passwords, health information, and financial data. That report is not a closed incident: the same underlying shape -- a database left in test mode, or a hand-written rule broader than intended -- keeps showing up in security research, bug-bounty write-ups, and breach disclosures in the years since, because the failure mode is structural rather than a one-time bug. Nothing in the SDK or the client stops a developer from shipping against an open database; only the rules do, and rules are opt-in.
A project can have correct, carefully written rules on 30 collections and a 31st, added in a later feature, that nobody wrote a rule for -- Firestore and the Realtime Database do not require every path to have an explicit rule before it can be read; an absent or overly broad rule simply falls through to whatever the closest matching rule allows. The Firebase console's own Rules Playground can catch this, but only for someone logged in as a project member who thinks to run it against the new path -- which is exactly the moment a live check from the outside, using only the project ID and database URL any visitor's browser already has, earns its keep.
A free tool that runs exactly the check above -- a shallow, read-only request to your Realtime Database root, and one capped request per Firestore collection you name -- is at the Firebase security rules exposure checker. It runs entirely in your browser for the Realtime Database half (or as a CLI for CI, and for Firestore if your browser blocks the cross-origin request), and never sends your project ID, database URL, or anything it reads back to any server of ours. As with any tool that sends requests to a project you name, only run it against one you own or are authorised to test.