Getting Started with Firestore Security Rules

1. Introduction

This tutorial aims to provide you with the necessary knowledge to write Firestore Security Rules. Security rules are essential in safeguarding your Firestore database by determining who has read and write access to your database.

By the end of this tutorial, you will:

• Understand Firestore Security Rules.
• Be able to write basic and complex security rules.
• Gain insights into best practices.

Prerequisites:

• Basic understanding of Firestore and its data model.
• Familiarity with JavaScript or similar programming languages.

2. Step-by-Step Guide

Firestore Security Rules use a syntax that resembles JavaScript, with some differences. The rules are composed of service blocks that specify the service, match statements that specify document paths, and allow expressions that grant access.

Basic Rule

Here is a basic example:

service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if false;
    }
  }
}

In the code above, {document=**} matches request to any document in the database, and allow read, write: if false; denies all read and write operations.

Rules are not Filters

One key concept to understand is that security rules are not filters. Firestore does not filter data on the server. Rather, it checks each query against its potential result set.

Rules Evaluation

Rules are evaluated in the order they are defined, but only the first matching allow expression is evaluated.

3. Code Examples

Example 1: User-Based Access

This rule allows a user to read and write their own documents.

service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read, write: if request.auth.uid == userId;
    }
  }
}

In the code above, request.auth.uid represents the ID of the user making the request, and userId is the ID of the user document being accessed.

Example 2: Role-Based Access

This rule allows only users with the role 'admin' to write data.

service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == 'admin';
      allow read: if true;
    }
  }
}

This rule retrieves the role field of the user document and checks if it's 'admin'.

4. Summary

We've covered how to write basic and more complex Firestore Security Rules. We've also looked at how rules are not filters and their evaluation order.

Next, try to write rules for your own Firestore database. Remember to always test your rules thoroughly before deploying.

5. Practice Exercises

1. Write a rule that allows a user to update their document only if the email field stays the same.
2. Write a rule that allows read access to a document only if the published field is true.

Solutions

service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow update: if request.auth.uid == userId && request.resource.data.email == resource.data.email;
    }
  }
}

This rule checks if the email field in the new data (request.resource.data.email) is the same as the email field in the existing document (resource.data.email).

service cloud.firestore {
  match /databases/{database}/documents {
    match /articles/{articleId} {
      allow read: if resource.data.published == true;
    }
  }
}

This rule allows reading an article document only if the published field is true. It doesn't check who the user is, so it applies to all users.

Keep practicing by writing rules for different scenarios and testing them out.