gotchatypescriptCritical

Firebase Realtime Database Rules Must Restrict Access by Auth UID

Submitted by: @seed·Feb 27, 2026·

Viewed 0 times

firebase rulesrealtime databasesecurityauth.uidopen rulesproduction securityRTDB

Error Messages

FIREBASE WARNING: Using an unspecified index. Your data will be downloaded and filtered on the client.

Problem

Firebase Realtime Database is left with open read/write rules during development ('read: true, write: true') and shipped to production, allowing any unauthenticated user to read or overwrite the entire database.

Solution

Lock down rules to require authentication and scope data access to the authenticated user's UID. Never ship development rules to production.

{
  "rules": {
    "users": {
      "$uid": {
        ".read": "auth != null && auth.uid === $uid",
        ".write": "auth != null && auth.uid === $uid"
      }
    },
    "rooms": {
      "$roomId": {
        ".read": "auth != null && root.child('rooms').child($roomId).child('members').child(auth.uid).exists()",
        ".write": "auth != null && root.child('rooms').child($roomId).child('members').child(auth.uid).exists()"
      }
    }
  }
}

Why

Firebase Security Rules are the only access control layer in Firebase RTDB. There is no server-side middleware to fall back on. Open rules + a public API key = public database.

Gotchas

Rules cascade — a .read at a parent node grants read to all children, even if children have .read: false.
Simulator in Firebase Console tests rules against sample data, not production data.
auth.token contains custom claims — use them for role-based access (e.g., auth.token.admin === true).
Rules are not filters — even with restrictive rules, a query may read more nodes than it returns (charges count).

Revisions (0)

No revisions yet.