This was a different way of thinking about security rules for us. But basically you have to make everything not readable and not writable at the root and then open up access farther down. And the way you need to structure your data will be affected. You might have a "user" level in the tree but you make a child level "private" readable by the actual user and no one else, like /users/$userId/private. Then you might have a /users/$userId/public that anyone can read, etc.<p>We also don't allow any writing directly to the data nodes but rather have a separate level in the tree where "requests" are written, then a privileged process reads, processes, and writes to the main data nodes, then notifies the client it's done by writing to a "response" node that only the client can read. This helps us make the security rules a little simpler and less error prone to mistakes, but primarily it's so we have a hook to run business processes and validation that doesn't need to be in the client which is unsafe.<p>I'd recommend using the bolt compiler (<a href="https://github.com/firebase/bolt" rel="nofollow">https://github.com/firebase/bolt</a>) so that you can write rules using repeatable logic and so that you can actually read complex rules.