19. Securing Data in Cloud Firestore

Written by Dean Djermanović

In the previous chapters, you implemented all of the features to the WhatsUp app except the most important one. You haven’t implemented any security rules, which means anyone has access to your data.

In this chapter, you’ll learn what security rules in Cloud Firestore are and how to add them to your database to make your data safe.

What are security rules?

To set up your own security system you’d need to set up your own server that acts as a proxy between your mobile clients and the remote database. That server would need to process all of the requests that are sent to the database and make sure that the client is accessing only the data that it is allowed to see.

Security rules handle security for you. You don’t need to set up your own security system.

How security rules work?

Security rules check the requests that are coming to the database and lets through those that satisfy the criteria and reject the ones that don’t. So for example, if your database only allows writing data to the authenticated client and an unauthenticated user tries to write something to the database, then that request would be rejected.

Any request that comes to the database involves the document. You’re either trying to write the document to the database, read the document from the database, update an existing document, or something similar. Cloud Firestore will take a look at the security rules that apply to the document that you request contains. It will then run a set of tests that you wrote to determine if the request is allowed or not.

In a nutshell, security rules consist of two things:

1. Specifying which documents you are securing.
2. What logic you’re using to secure them.

Getting started

To see how the security rules look like open your Firestore database in the console. You’ll see Rules tab at the top. Click on it. Then click on the Simulator icon to expand the simulator window:

This is where you can see your current logic for the security rules.

You’ll take a deeper look into these rules next.

match /databases/{database}/documents

This line indicates the path that all the documents belong to. By default, all the documents belong to the /databases/{database}/documents path.

match /{document=**} {
      ...
}

This is where you set the rules for the specific document by specifying the path to that document. match statement specifies the path to the document. document=** is a recursive wildcard which matches any document in the entire database. As of May 2019, there is version 2 of the Cloud Firestore security rules which changes the behavior of the recursive wildcards. Check the official documentation https://firebase.google.com/docs/firestore/security/get-started#security_rules_version_2 to see the differences in the behavior.

In your current database, you have a posts collection that contains a specific post. The path to the specific post looks like this:

/databases/{database}/documents/posts/{postId}

If you only want to write a security rule that applies to that specific path you’d do it like this:

match /databases/{database}/documents {
    match posts/{postId} {
      ...
    }
}

As you can see, Firestore lets you nest the paths.

The first match you see will almost always look like this:

match /databases/{database}/documents

{database} in curly brackets is a wildcard that matches any database name. You’ll learn more about wildcards later.

Now, your posts collection could have a subcollection. You could add a separate rule for that subcollection like this:

match /databases/{database}/documents {
    match posts/{postId} {
      match subcollection/{documentId} {
          ...
      }
    }
}

There is one important thing to notice when looking at these nested rules. The rules you add to the top level match posts/{postId} do not apply to the inner match statements. Security rules in Cloud Firestore do not cascade.

Adding security rules

Your WhatsUp app is still not safe. You’ll add security rules next to restrict the access to data. Open Firestore database in the Firebase console and click on the Rules tab. Add the following rule:

service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if request.auth.uid != null;
    }
  }
}

This rule allows read and write access on all documents for any signed in user. The allow expression specifies when the writing or reading the data is allowed.

When you’re done with writing the rules to the editor click Publish:

Usually, it takes a minute for the security rules to make an effect, but sometimes it can take up to 10 minutes. Before you start testing make sure you wait a couple of minutes.

Testing the security rules

You have already seen a Simulator window in the Firebase console. This is a nice feature that Firestore provides that you can use to test your rules.

Click on the Data tab, open posts collection and copy the ID of one post. Go back to the Rules tab and click on the Simulator to open simulator window.

1. Under the Simulation type field leave it set to get.
2. Under the Location field enter the path to the specific post. In my case the path looks like this:

posts/0gbGvf23YT2xhRpcMxqt

The 0gbGvf23YT2xhRpcMxqt is the ID of the post. Replace that value with the ID you copied earlier.

Leave the Authenticated switch in the inactive state.

Now, click the Run button. You should see an error message:

Your request didn’t succeed because you simulated unauthenticated request.

Now change the Authenticated switch to active state, leaving the authentication fields that appear with their default values, and click Run again:

Your request is now successful.

Key points

• Security rules check the requests that are coming to the database and lets through those that satisfy the criteria and reject the ones that don’t.
• Security rules consist of two things: 1. Specifying which documents you are securing; 2. What logic you’re using to secure them.
• In the Rules tab in the Firebase console, you can see your current security configuration.
• match statement specifies the path to the document.
• allow expression specifies when the writing or reading the data is allowed.
• Security rules in Cloud Firestore do not cascade.
• Cloud Firestore provides Simulator feature that you can use to test your rules.

Where to go from here?

In this chapter, you learned the basics of the Cloud Firestore’s Security rules. Your WhatsUp app now only allows authenticated users to access the data.

To learn more about writing conditions, structuring and testing Security rules check out the official guidelines https://firebase.google.com/docs/firestore/security/rules-structure