By default, Firebase sets the rules for users to authenticate before writing or reading operations. We can go to our project in Firebase console and choose the Database option in the left-hand options panel and go to the Rules tab in the Main panel. The default rules are as follows:

{
 "rules": {
 ".read": "auth != null",
 ".write": "auth != null"
 }
}

The following screenshot shows the default security configurations for any Realtime Database project:

Firebase offers a unique way to examine rules in the simulator. In the right-hand corner of the Firebase console's Main window, you will notice a blue button labelled as SIMULATOR, click on it to have a perceptible familiarity. Now we can see that there are two checkboxes and one input field to enter the URL and a toggle button indicating Authenticated. If you toggle it towards the right side, you will see a drop-down allowing you to choose the security provider, and it will also show UID and auth token payload. When we click on the RUN button, it will show the possible responses. 

The following screenshot shows the Simulator in a default state:

If we press the RUN button, the simulator assumes that the user continues not-authenticated, and it will return a Simulated read denied error. 

The following screenshot illustrates the not-authenticated user's state:

Since now we know what a simulator is, let's check what happens when we push the toggle button and choose a provider:

It will grant the access to the database. Likewise, we can run the test on the write operation and understand what happens behind the screen.

Typically, there are four types of database rules. These rules dictate different responsibilities:

Customizing database rules

Database rules are versatile and powerful and if we want to customize certain operations we can achieve it through rules. For instance, if we require giving access to read all the data and no write access to users, we can achieve this by using the following rules:

{
"rules": {
".read": true,
".write": false
}
}

The preceding rules will allow the user to have a read access to the database. Since there isn't any path specified, the complete database is readable, but not writable. If we want to customize on node basis we can take the node name into the rules and we can give the rules as follows. Test the rules in the simulator before publishing them:

{
"rules": {
".write" : false,
"Donor" : {
".read" : true
}
}
}

The following screenshot illustrates custom rules for read-write access to a particular node:

We can customize the rules to a level where we can specify which node needs to be read, which node can be written, which cannot be written, and a lot more.

Data security

Another outstanding feature of Firebase is security. Ensuring that no data is being given access to the unapproved or not-authenticated users. For this problem there is a variable named auth. It is a predefined variable within the database rules. It contains the auth provider, used auth ID, and token and user's UID. Using this we can restrict the database access and grant the application on a use case basis. Consider the following diagram for apprehending the security. There are blood donors and the details are helpful for having authentic donor information:

Consider the following rules that allow only authenticated users to read the data:

 {
"rules": {
".write" : false,
"Donor" : {
"$uid": {
".read": "auth != null && auth.uid == $uid"
}
}
}
}

The following screenshot shows the simulated authenticated user:

In previous examples, we have seen how to set the rules, how to use the predefined variables of rules, and so on. Now let's understand what custom variables are. Anything that has $ and the name that describes the node will be a variable that we can use in rule expressions. Say for instance, the value allocated to the UID will, obviously, rely upon which node is being read, since every user ID node will have a unique value doled out to it. The $ variable gives an approach to store the value to the key and reference rule expressions.

With the ability to create custom variables, Firebase has predefined variables that can be used in database rules in many use cases. The following is a list of predefined variables:

".write" : "data.child('Donor').child('Name').child('userid').child('email').exists()"