Rtdb Security Rules

RTDB Security Rules

RTDB rules are JSON-embedded expressions where access cascades downward: a permissive parent grants every descendant, and a restrictive child cannot revoke it. Lock the root, then open the smallest useful paths.

Rule types

• .read / .write — WHO may act at this path (and everything below it).
• .validate — WHAT the written data may look like, evaluated only after .write allows; validations do not cascade.
• data — pre-write state (the actor's existing context); newData — post-write state. In multi-field writes each .validate sees the full merged newData.

Steps

1. Read current rules. From database.rules.json in the project, or the deployed ruleset read back through the Firebase Console or firebase-tools. Complete when you can state the effective access at every path a client touches (walk each cascade from root).

2. Identify paths and identities. List each path clients read or write and the identity that should reach it (anonymous, any signed-in user, owner via auth.uid, role via claim). Complete when each path has an intended identity × operation table.

3. Design access and validation together. Start from { "rules": { ".read": false, ".write": false } } and open exact paths. Guard identity with auth !== null before auth.uid comparisons. Add a .validate for every user-controlled write: type checks (newData.isString(), .isNumber()), bounds, required children (newData.hasChildren([...])), and transition checks comparing data to newData. Complete when every open path has both an access rule and a shape rule.

4. Simulate before shipping. Run rtdb_simulate_access for each path with four case families: the intended actor allowed, anonymous denied, cross-user denied, invalid shape denied. Complete when all four families pass per path.

5. Deploy. Write the full database.rules.json, since a deploy replaces the entire ruleset, and ship it with firebase deploy --only database or the Console. Complete when the deployed rules, read back through the Console or firebase-tools, match the file, and rtdb_simulate_access against a local copy of the same file still passes every case from step 4.

Reference — pitfalls

• A .read: true near the root silently exposes every descendant; recheck cascades after any parent edit.
• .validate never runs when .write denies — and never rescues a .write that is too broad.
• data at a path being created is empty; existence checks belong on data.exists().
• Deleting a node is a write of null: newData.exists() in .validate blocks deletion — decide intentionally.