Firebase Realtime Database Security Rules allow you to control access to data storedin your database. The flexible rules syntax allows you to createrules that match anything, from all writes to your database to operationson individual nodes.

Realtime Database Security Rules aredeclarative configuration for your database. This meansthat the rules are defined separately from the product logic. Thishas a number of advantages: clients aren't responsible for enforcing security, buggyimplementations will not compromise your data, and perhaps most importantly,there is no need for an intermediate referee, such as a server, to protect datafrom the world.

This topic describes the basic syntax and structure Realtime Database Security Rulesused to create complete rulesets.

Structuring Your Security Rules

Realtime Database Security Rules are made up of JavaScript-like expressions contained in aJSON document. The structure of your rules should follow the structure of thedata you have stored in your database.

Basic rulesidentify a set of nodes to be secured, theaccess methods (e.g., read,write) involved, andconditions under which access is either allowed or denied.In the following examples, ourconditions will be simpletrue andfalse statements, but in the next topic we'll cover more dynamic ways toexpress conditions.

So, for example, if we are trying to secure achild_node under aparent_node,the general syntax to follow is:

{  "rules": {    "parent_node": {      "child_node": {        ".read": <condition>,        ".write": <condition>,        ".validate": <condition>,      }    }  }}

Let's apply this pattern. For example, let's say you are keeping track of a listof messages and have data that looks like this:

{  "messages": {    "message0": {      "content": "Hello",      "timestamp": 1405704370369    },    "message1": {      "content": "Goodbye",      "timestamp": 1405704395231    },    ...  }}

Your rules should be structured in a similar manner. Here's a set ofrules for read-only security that might make sense for this data structure. Thisexample illustrates how we specify database nodes to which rules apply and theconditions for evaluating rules at those nodes.

{"rules":{//Forrequeststoaccessthe'messages'node..."messages":{//...andtheindividualwildcarded'message'nodesbeneath//(we'll cover wildcarding variables more a bit later)...."$message":{//Foreachmessage,allowareadoperationif<condition>.Inthis//case,wespecifyourconditionas"true",soreadaccessisalwaysgranted.".read":"true",//Forread-onlybehavior,wespecifythatforwriteoperations,our//conditionisfalse.".write":"false"}}}}

Basic Rules Operations

There are three types of rules for enforcing security based on the type ofoperation being performed on the data:.write,.read, and.validate. Hereis a quick summary of their purposes:

{"rules":{"rooms":{//thisruleappliestoanychildof/rooms/,thekeyforeachroomid//isstoredinside$room_idvariableforreference"$room_id":{"topic":{//theroom's topic can be changed if the room id has "public" in it".write":"$room_id.contains('public')"}}}}}

{  "rules": {    "widget": {      // a widget can have a title or color attribute      "title": { ".validate": true },      "color": { ".validate": true },      // but no other child paths are allowed      // in this case, $other means any key excluding "title" and "color"      "$other": { ".validate": false }    }  }}

{  "rules": {     "foo": {        // allows read to /foo/*        ".read": "data.child('baz').val() === true",        "bar": {          /* ignored, since read was allowed already */          ".read": false        }     }  }}

{  "rules": {    "records": {      "rec1": {        ".read": true      },      "rec2": {        ".read": false      }    }  }}

vardb=firebase.database();db.ref("records").once("value",function(snap){// success method is not called},function(err){// error callback triggered with PERMISSION_DENIED});

FIRDatabaseReference*ref=[[FIRDatabasedatabase]reference];[[_refchild:@"records"]observeSingleEventOfType:FIRDataEventTypeValuewithBlock:^(FIRDataSnapshot*snapshot){// success block is not called}withCancelBlock:^(NSError*_Nonnullerror){// cancel block triggered with PERMISSION_DENIED}];

varref=FIRDatabase.database().reference()ref.child("records").observeSingleEventOfType(.Value,withBlock:{snapshotin// success block is not called},withCancelBlock:{errorin// cancel block triggered with PERMISSION_DENIED})

FirebaseDatabasedatabase=FirebaseDatabase.getInstance();DatabaseReferenceref=database.getReference("records");ref.addListenerForSingleValueEvent(newValueEventListener(){@OverridepublicvoidonDataChange(DataSnapshotsnapshot){// success method is not called}@OverridepublicvoidonCancelled(FirebaseErrorfirebaseError){// error callback triggered with PERMISSION_DENIED});});

curl https://docs-examples.firebaseio.com/rest/records/# response returns a PERMISSION_DENIED error

Since the read operation at/records/ is atomic, and there's noread rule that grants access to all of the data under/records/,this will throw aPERMISSION_DENIED error. If we evaluate thisrule in the security simulator in ourFirebase console, we can see thatthe read operation was denied because no read rule allowed access to the/records/ path. However, note that the rule forrec1was never evaluated because it wasn't in the path we requested. To fetchrec1, we would need to access it directly:

vardb=firebase.database();db.ref("records/rec1").once("value",function(snap){// SUCCESS!},function(err){// error callback is not called});

FIRDatabaseReference*ref=[[FIRDatabasedatabase]reference];[[refchild:@"records/rec1"]observeSingleEventOfType:FEventTypeValuewithBlock:^(FIRDataSnapshot*snapshot){// SUCCESS!}];

varref=FIRDatabase.database().reference()ref.child("records/rec1").observeSingleEventOfType(.Value,withBlock:{snapshotin// SUCCESS!})

FirebaseDatabasedatabase=FirebaseDatabase.getInstance();DatabaseReferenceref=database.getReference("records/rec1");ref.addListenerForSingleValueEvent(newValueEventListener(){@OverridepublicvoidonDataChange(DataSnapshotsnapshot){// SUCCESS!}@OverridepublicvoidonCancelled(FirebaseErrorfirebaseError){// error callback is not called}});

curl https://docs-examples.firebaseio.com/rest/records/rec1# SUCCESS!

Overlapping Statements

It's possible for a more than one rule to apply to a node. In thecase where multiple rules expressions identify a node, the access method isdenied ifany of the conditions isfalse:

{  "rules": {    "messages": {      // A rule expression that applies to all nodes in the 'messages' node      "$message": {        ".read": "true",        ".write": "true"      },      // A second rule expression applying specifically to the 'message1` node      "message1": {        ".read": "false",        ".write": "false"      }    }  }}

In the example above, reads to themessage1 node will bedenied because the second rules is alwaysfalse, even though the firstrule is alwaystrue.

Next steps

You can deepen your understanding of Firebase Realtime Database Security Rules:

• Learn the next major concept of theSecurity Rules language, dynamicconditions, which let yourSecurity Rules check userauthorization, compare existing and incoming data, validate incoming data, checkthe structure of queries coming from the client, and more.

• Review typical security use cases and theFirebase Security Rules definitions that address them.