After test mode expired, your Realtime Database started denying requests. The rule you wrote to get it working again now lets signed-out visitors read session, player and presence data. The usual cause is a blanket ".read": true at the root or at a parent node. It applies to every child beneath it.
Test-mode rules are world-readable and world-writeable for a trial period. After it, Firebase warns by email and then denies requests. Pasting ".read": true back in at the root brings the app back, but it also makes the whole tree readable without sign-in.
How to tell: The published rules contain ".read": true at the root, or on a node such as /sessions, /players or /presence, and a read simulated without authentication succeeds.
Rules for .read and .write cascade downward, and a rule higher in the tree overrides a deeper one. A strict rule on players/$uid has no effect if a parent node already grants read access.
How to tell: A read at the parent path (for example /players) succeeds without sign-in, although the child rule under it requires auth.uid to match.
If the project deploys rules with the Firebase CLI, the .rules file in the project directory replaces whatever is in the console. A fix made in the console gets undone by the next deploy.
How to tell: The Rules tab was correct after you published, then showed the open rule again after a deploy, and the .rules file in the repo still contains it.
In the Firebase console, select your project, choose Realtime Database, then click Rules. Read what is published now, not what you remember pasting.
Look for ".read": true, or a read condition that does not depend on auth, at the root or on a parent of sessions, players and presence. A grant at a parent covers the children below it.
{
"rules": {
".read": true,
".write": true
}
}Open the Rules Playground from the Rules editor, set it to simulate a read, and click Run for each of the three paths without signing in. If the read succeeds, the rules are the cause, not the client code.
Remove the root ".read" and ".write" and scope each node to the signed-in owner using a $uid capture variable. This assumes these nodes are keyed by user ID. Adjust the key if yours are not.
{
"rules": {
"players": {
"$uid": {
".read": "auth.uid === $uid",
".write": "auth.uid === $uid"
}
},
"sessions": {
"$uid": {
".read": "auth.uid === $uid",
".write": "auth.uid === $uid"
}
},
"presence": {
"$uid": {
".read": "auth.uid === $uid",
".write": "auth.uid === $uid"
}
}
}
}If other players must see a node such as presence, put the read rule on that child path, not on a parent, because shallower rules override deeper ones. Keep writes tied to auth.uid === $uid. Treat a sign-in-only read as a deliberate decision, since the docs advise against leaving data open to any signed-in user.
Click Publish in the console once the Playground results match what you expect. If the project uses the CLI, put the same rules in the .rules file and deploy it, so the next deploy does not restore the open rule.
firebase deploy --only databaseQuick check: Rules tab: search for ".read": true on the root or /sessions, /players, /presence; simulate a read in Rules Playground
1 of the 701 verified cases from the last 12 months in our data match this symptom (0.1%). The most common cause was “A blanket ".read": true replaced the expired test-mode rules” (1 of 1). How we collect and verify cases.
On Gemmein, each collection has exactly one rule that decides who may read and write it. The options beside a rule only hide or order records and never let anyone read a record the rule keeps from them. For state that no app session should read, the app_only rule answers 403 app_only to every app read and write, and signing in changes nothing.
No. Test-mode rules are world-readable and world-writeable during the trial period. After it, Firebase sends an email and then denies requests. Public reads after expiry usually come from rules written afterwards.
It restricts reads to signed-in users, but the Firebase docs do not recommend leaving data accessible to any signed-in user. Compare auth.uid with the $uid path variable to scope data to its owner.
No. The Realtime Database docs state that .read and .write rules shallower in the database override deeper rules, so remove the grant at the parent.
Locked mode denies reads and writes from mobile and web clients. The docs say authenticated application servers can still access your database.
Every cause and step above was checked against these pages on 20 Oct 2026.
This is one symptom of a wider failure pattern: Users can see other users' data: fixing RLS and access rules. The guide covers every cause we see for it, on any stack.