How do similar writes give different results in Firebase security rules?

0
votes

Can someone please explain why, while testing Firebase security rules the below two simulated writes which I think are essentially the same give different results?

Write1

Simulator location: /users/id123/state
Simulator data(JSON): {"data":"example}

Write2

Simulator location: /users/id123/
Simulator data(JSON): {"state":{"data":"example}}

Write 1 denies the wright at the "state":, ".write" line in the below rules.

Write 2 skips the "state":, ".write" line altogether.

This is an issue because I am updating multiple paths in one JSON update and its skipping rules.

Does anyone know why?

{  
    "rules":{  
        "users":{  
            "$userId":{  
                "state":{  
                    ".write":false,
                    ".read":false
                }
            }
        }
    }
}
2
firebasefirebase-realtime-databasefirebase-security
None of your rules give anyone permission to write anywhere in the database. All writes from regular users should fail with these rules, regardless of the location they write to. Writes from an administrative user will always succeed, because their access bypasses the rules. How are you testing the writes? Can you give me the minimal steps with which I can reproduce what you see? – Frank van Puffelen

2 Answers

0
votes

In the example you gave you are writing to different locations and firebase security will first look at the location you are writing at to check the rules.

Write2

Simulator location: /users/id123/
Simulator data(JSON): {"state":{"data":"example}}

Here you are writing to /users/id123/ and firebase will check that location for a write rule which in you case isn't present so it will use the default ".write":false.

For writing your rules you have to make sure to set them at the correct level.

Take a look at firebase security authorization (who can read/read) and also validation (what can be written).

0
votes

Your rule is for denying writes at all the locations at or deeper under your state node.

So any writes at 

/Users/uid/state

And any rules under states

/Users/uid/state/foo/bar

Will be denied.

But if you write the data to

/Users/uid

The rule doesn't apply as it's not at or under the state node, it's a shallower node which doesn't have any rules stated. You can put your rules at 

{  
"rules":{  
    "users":{  
        "$userId":{  

                  ".write":false,
                  ".read":false

            }
        }
    }
}

The rules above will prevent writes for all the paths under your uid node. Also if you are using the REST api or the admin api, all rules will get bypassed

The REST API and the ADMIN API will both need a service account key file that only you will have. Thus they are secure. They'll give you admin access and will always bypass all security rules at all locations.