Rules Cascade
Read and Write rules cascade. It means that granting read/write access to a node grants read/write access to all of its child nodes.
In order to demonstrate what can go wrong I will outline two examples, based on real projects.
Consider the following trivial rules:
Anyone can read and write /. Let’s say that we want to add a node to the database for user sessions and grant read and write permissions for a session, only to the user who owns that session (e.g only a user with uid bob can read and write /sessions/bob).
Take a look at the following rules:
Now, only bob can read and write /sessions/bob and nobody can read and write /sessions, right?
Unfortunately, the opposite is true. Anyone can read and write /sessions/bob. Actually anyone can read and write /, and there is no difference between these rules and the first ones.
They are completely equivalent, because read and write rules cascade.
The correct way to obtain the desired functionality is:
Note that I omitted the "read": false and the "write": false under session since the default access is false.
Our second example is:
Any authenticated client can read and write /users, but due to the rules under /users/$uid we can infer that allowing such access was not intentional.
Similar to the first example, the fix should be:
What should you do?
You should take your time writing security rules as it is critical to your application security. Cascading rules bugs occurs because of lack of understanding in Firebase rules or poor maintenance.
Changes to your security rules should be tested and monitored as a part of your development life cycle.
In order to do so, we recommend using the Bolt compiler to simplify the process of writing rules and Targaryen to test your rules according to specific scenarios in your application.
We at Noless provide security scans specifically designed for applications that are built using serverless technologies. Learn more about serverless security here.