A deeper Firebase rule cannot take access away

Symptom

A child path sets ".read": false, and clients can still read it.

Root cause

Firebase documents that Realtime Database rules cascade. A read allowed at a parent path is not revoked by a child. The insecure example on the rules page allows read of /foo when a child field matches, then sets ".read": false on /foo/bar. That child rule is ignored because read was already allowed. Child rules can only grant additional privileges.

In this project's Realtime Database rules, do not try to lock a child under a parent that already allows read or write.

Write the broader rule at the parent only when every child is meant to be readable. Put private data on a sibling path with its own rule, instead of a nested ".read": false. Deploy to your own database and read the private path as a user who should not have it. The read must fail.

Paste this into the coding tool that has your own project open.

2-minute self-check

These steps are for an app you own. Do not run them against someone else's project.

1. Open your own Realtime Database rules. Find any ".read": false or ".write": false nested under a parent that already allows that operation.
2. Those nested denies do not apply. Move the private data to a path the parent rule does not cover.
3. In the Rules Simulator for your project, read the private path as the wrong user and confirm it is denied.

Sources

• Firebase: Avoid insecure rules (cascading rules)