Reference detail

Apps with a Firebase Realtime Database

Android apps that ship a Firebase Realtime Database URL. A reference is not an exposure; it becomes one when the rules let an unauthenticated caller read the data, which a scan checks and records the date of.

Mapped findings are review signals. Interpret each app’s build, scan date and coverage before drawing a conclusion. Historical verification describes only its recorded scan time.

What this finding means

The Firebase Realtime Database stores an app's data as a single JSON tree reached over HTTPS and a websocket. An app that uses it ships the database URL, which is all a client needs to start making requests.

We have recorded a Realtime Database reference in 3,023 apps. The reference tells you the app has one; it does not tell you whether the rules let anyone read it.

Why the rules are where this goes wrong

Access is controlled by a rules document attached to paths in the tree, and two properties of that design account for most exposures. Rules are evaluated at the shallowest matching path and then stop, so a permissive rule high in the tree grants everything beneath it and no deeper rule can take that back. And because the tree is a single document, nothing separates a public catalogue from a user's private records unless someone deliberately creates that boundary.

The other common cause is test mode. Creating a database offers rules that allow all reads and writes for thirty days, meant as scaffolding. The thirty days expire quietly, and an app shipped against those rules stays open until somebody looks.

This is also a legacy product. Firestore is the current default, so Realtime Database rules are often the oldest security configuration in a project and the least likely to have been revisited.

How to fix it

Read your rules from the root down and find the shallowest path granting read or write. That rule, not the deepest one, is your actual exposure.
Never ship test-mode rules; replace allow-all with explicit conditions before the first release.
Scope user data under a path keyed by the authenticated uid and require auth.uid to match it.
Test with the rules simulator against a path you believe is private, as an unauthenticated user.
Validate writes as well as reads: an open write path lets anyone replace the data your app depends on.

How we detect it, and what it cannot tell you

The database URL is matched in the APK's resources and compiled code and recorded in redacted form. A reference on its own is reported at low severity.

A finding escalates only when an unauthenticated request confirmed the database answers one, and each escalated finding carries a stored record of that check. Where we have not confirmed it, treat the finding as a prompt to review your own rules, which takes seconds and which we cannot do for you.

Mapped checks & review guidance (1)

Firebase Realtime Database reference

Confirm the bucket/database denies anonymous read (enable auth / storage rules / RLS), then audit its contents for data already exposed while it was open.

Browse this category