Firebase Realtime Database Security Rules determine who has read and write access to yourdatabase, how your data is structured, and what indexes exist. These rules liveon the Firebase servers and are enforced automatically at all times. Every readand write request will only be completed if your rules allow it. By default,your rules do not allow anyone access to your database. This is to protect yourdatabase from abuse until you have time to customize your rules or set upauthentication.

Realtime Database Security Rules have a JavaScript-like syntax and come in four types:

Realtime Database security overview

TheFirebase Realtime Database provides a full set of tools for managing thesecurity of your app. These tools make it easy to authenticate your users,enforce user permissions, and validate inputs.

Firebase-powered apps run more client-side code than those with many othertechnology stacks. Therefore, the way we approach security may be a bitdifferent than you're used to.

A common first step in securing your app isidentifying your users. This process is calledauthentication.You can useFirebase Authenticationto have users to sign in to your app. Firebase Authenticationincludes drop-in support for common authentication methods like Google andFacebook, as well as email and password login, anonymous login, and more.

User identity is an important security concept. Different users have differentdata, and sometimes they have different capabilities. For example, in a chatapplication, each message is associated with the user that created it. Usersmay also be able to delete their own messages, but not messages posted by otherusers.

Authorization

Identifying your user is only part of security. Once you know who they are, youneed a way to control their access to data in your database. Realtime Database Security Rulesallow you to control access for each user. For example, here's a set ofsecurity rules that allows anyone to read the path/foo/, but noone to write to it:

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

.read and.write rules cascade, so this rulesetgrants read access to any data at path/foo/ as well as any deeperpaths such as/foo/bar/baz. Note that.read and.write rules shallower in the database override deeper rules, soread access to/foo/bar/baz would still be granted in this exampleeven if a rule at the path/foo/bar/baz evaluated to false.

The Realtime Database Security Rules include built-in variablesand functions that allow youto refer to other paths, server-side timestamps, authentication information,and more. Here's an example of a rule that grants write access forauthenticated users to/users/<uid>/, where <uid> isthe ID of the user obtained throughFirebase Authentication.

{  "rules": {    "users": {      "$uid": {        ".write": "$uid === auth.uid"      }    }  }}

Data validation

TheFirebase Realtime Database is schemaless. This makes it easy to change thingsas you develop, but once your app is ready to distribute, it's important fordata to stay consistent. The rules language includes a.validaterule which allows you to apply validation logic using the same expressions usedfor.read and.write rules. The only difference isthatvalidation rules do not cascade, so all relevantvalidation rules must evaluate to true in order for the write to be allowed.

These rule enforce that data written to/foo/ must be a stringless than 100 characters:

{  "rules": {    "foo": {      ".validate": "newData.isString() && newData.val().length < 100"    }  }}

Validation rules have access to all of the same built-in functions andvariables as.read and.write rules. You can usethese to create validation rules that are aware of data elsewhere in yourdatabase, your user's identity, server time, and much more.

{  "rules": {    "dinosaurs": {      ".indexOn": ["height", "length"]    }  }}