Apps with Cloud Firestore findings

Why this list is short

Cloud Firestore is Google's current default database for mobile apps, storing documents in collections rather than one JSON tree. Most new Firebase projects use it.

This category lists 0 apps, and that is not because Firestore is rare. Unlike the Realtime Database, Firestore gives an app no distinctive per-project URL to find in a binary, so we never report it from a static reference. It appears here only where a check confirmed a project's data is readable without authentication.

An empty or short list therefore means we have confirmed few, not that few exist. Verification across the corpus was restored at the end of September 2026 and the re-scan is still running, so this count can only grow.

Why Firestore rules fail differently

Firestore rules match document paths, and the rule that catches people is that they do not cascade the way a filesystem would. A rule on /users/{uid} does not apply to /users/{uid}/private/{doc} unless it is written recursively.

The remedy for that, the {document=**} recursive wildcard, is also the most common over-correction. Written at a collection root with a permissive condition, it grants access to every subcollection beneath it, including ones added months later by a feature nobody reviewed.

Queries add a further subtlety. Firestore evaluates rules per document, so a query that would return a document the caller cannot read fails rather than silently filtering it out. Developers sometimes loosen a rule to make a query work, which grants more than the query ever needed.

How to fix it

• Write rules per collection and test subcollections explicitly; assume nothing is inherited.
• Use {document=**} deliberately, and only where every current and future descendant should share the same condition.
• Require request.auth and compare it against a field on the document or against the path, not merely that someone is signed in.
• Use the rules unit-testing library so a new subcollection cannot quietly inherit a permissive rule.
• Remember the anonymous auth provider still produces an authenticated request: request.auth != null is not an access control.

How we detect it

Where a Firebase project is identified from the APK, one unauthenticated request against the Firestore REST endpoint for that project establishes whether it answers. The request carries no credential and reads only enough of the response to determine reachability.

Because the finding exists only where that check succeeded, every entry here carries a stored probe record — a URL, a status, a response size and a timestamp — rather than an inference drawn from a string in a binary.