Search⌘ K
AI Features
Home
Courses
A Complete Guide to Firebase on the Web

Cloud Firestore and Cloud Storage Security Rules

Understand how to create and implement Cloud Firestore and Cloud Storage Security Rules in Firebase. Learn the syntax, structure, and key concepts like service declaration, match blocks, and allow statements to control read and write access while ensuring data validation and security. Gain practical knowledge on handling user authentication and resource validation for secure data management.

We'll cover the following...

Unlike Realtime Database Security Rules which are formatted using the JSON syntax, Cloud Firestore and Cloud Storage Security Rules take a different format. They begin with a service declaration that defines the scope of the Security Rules by identifying the Firebase product to which they apply. It then contains the match declaration using one or more match blocks. These are used to specify the path to the document or file in the database or the storage bucket. The match blocks contain allow statements that determine the conditions to access the document or file in the path.

Cloud Firestore Security Rules

Cloud Firestore Security Rules use a syntax based on the Common Expression Language (CEL)The Common Expression Language (CEL) is a non-Turing complete language designed for simplicity, speed, safety, and portability. Its syntax looks nearly identical to expressions in C++, Java, and TypeScript. together with the match and allow statements that determine the access condition of the database.

The steps for writing Cloud Firestore Security Rules are outlined below:

  • To begin writing Cloud Firestore Rules, we must first indicate a syntax version using the rules_version statement. This is important because the Security Rules will be evaluated as v1 if none is provided. For this course, we’ll focus on v2.
  • Next is the service cloud.firestore declaration that defines the scope of these rules, which in this case is Cloud Firestore.
  • Now, we must define the match patterns to identify the path. From the Security Rules perspective, all documents in Cloud Firestore fall into the /databases/{database}/documents path. This path can be thought of as the root of the database. Therefore, it’s always the path defined in the first match block. Then, the next match block must contain the actual path to the document. While specifying paths, we can also declare possible wildcards in the paths using the curly braces, { }. These will match all documents existing on the defined path.
  • The match blocks contain allow expressions that determine the conditions to grant access to the defined path. These expressions require methods, like read or write, to describe the nature of the database access:
Go (1.16.5)
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userID} {         // matches any document in the path users/
      allow read: if <condition>;
      allow write: if <condition>;
    }
  }
}

There are some things worth noting about the Cloud Firestore Security Rules syntax:

  • All match statements must point to documents, not collections. The match statements must either point to specific documents—/users/test@educative.io—or match any document in the specific collection using wildcards.
  • It’s possible to break down the read and write methods into more explicit methods. Other supported methods include: get, list, create, update, and delete.

The data request made by the Cloud Firestore Client SDK is called the request object. This object has two main properties, auth and resource, used to write Security Rules. The auth object contains information about the signed-in user that we can use to define access conditions. The resource object contains information about the document being accessed. We can access the fields on the document using the data property on the resource object and then check these fields for validity and consistency:

Go (1.16.5)
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userID} {
      allow read: if request.auth.uid == userID;
      allow create: if request.resource.data.score is number &&
      		request.resource.data.score >= 5 &&
          request.resource.data.score <= 10;
    }
  }
}
  • Line 5: We define the access for the read method in the document path only allowing users access to documents with the same ID as their uid.
  • Line 6: We begin the first of a three-part condition attached to the create method that only allows users to write new documents where the score field is a number greater than or equal to 5 (as shown in line 7) and less than or equal to 10, (as shown in line 8).

Cloud Storage Security Rules

With Cloud Storage Security Rules, we can control access to objects and files stored in our Cloud Storage buckets. Cloud Storage Security Rules are similar to Cloud Firestore rules, and they both follow the same syntax:

  • They both begin with a declaration of the syntax version. We will also use the v2 for our Cloud Storage Security Rules.
  • Next is the service declaration. Cloud Storage Security Rules use the service firebase.storage declaration to define the scope of the rules.
  • Unlike Cloud Firestore Security Rules, all files in a Cloud Storage bucket fall into the /b/{bucket}/o path. This path can considered the root of the storage bucket. Therefore, it’s always the path defined in the first match block. Then, the next match block must point to a file in the bucket. They can either point to specific files—/images/logo.png—or use wildcards to match all files in a path —/images/{imageID}.
  • The match blocks contain allow expressions that determine the access conditions for the path:
Go (1.16.5)
rules_version = '2';
service firebase.storage {
  match /b/{bucket}/o {
    match /images/{imageID} {
  	  allow read: if <condition>;
      allow write: if <condition>;
    }
  }
}

Just like Cloud Firestore Security Rules, the data request made by the Cloud Storage Client SDK is accessible under the request object. Like Cloud Firestore’s request object, we have access to two properties on this request object, auth and resource. The auth object contains information about the signed-in user that we can use to define access conditions. The resource object contains information about the file being accessed. The resource object has properties that provide information about the file, such as the file name and other metadata that we can utilize in our Security Rules to ensure validity and consistency:

Go (1.16.5)
service firebase.storage {
  match /b/{bucket}/o {
    match /images/{imageId} {
      allow read: if request.auth != null
      // Only allow uploads of any image file that's less than 5MB
      allow write: if request.resource.contentType.matches('image/.*') && 
        request.resource.size < 5 * 1024 * 1024;
    }
  }
}
  • Line 4: We define the condition for the read access, ensuring that only authenticated users can read data from the path.
  • Lines 6 and 7: We begin the first of a two-part condition that allows users to write only image files that are less than five megabytes, to the path.

Note: Unlike Realtime Database Security Rules, Cloud Storage and Cloud Firestore Security Rules do not naturally cascade to lower paths. Therefore, we must always define rules for a specific document or file path in the database. Alternatively, we can use recursive wildcards to match all the documents, in a collection and its subcollection, and files in multiple Storage Bucket segments:

Go (1.16.5)
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
		match /users/{restOfPath=**} {
      allow read;
      allow write: if <condition>;
    }
  }
}

Recursive wildcards, {path=**} , apply Security Rules to an arbitrarily deep hierarchy. For instance, while matching documents in a Cloud Firestore collection, it will also match documents contained in deeply nested subcollections. Therefore, not only will the rules above match documents in the users/test@educative.io path, they will also match documents in the users/test@educative.io/tasks/{taskId} path. Hence, we must be careful if we need to use the values of the recursive wildcard variable in our Security Rules since the paths can change. Read more about Cloud Firestore and Cloud Storage recursive wildcards on the Firebase documentation.

Steps to perform

  • Read more about Cloud Firestore Security Rules on the Firebase documentation.
  • Head to the “Cloud Firestore” section of the Firebase console to write new security rules for your Cloud Firestore Database. These will allow reads to all documents in the users path but permit only authenticated users to write to it.
  • Read more on Cloud Storage Security Rules on the Firebase documentation.
  • Head to the “Cloud Storage” section of the Firebase console to write new security rules for your Cloud Storage bucket. These will allow reads to all files in the images path but permit only authenticated users to write to it. Include validation for the write operation to ensure that only images can be uploaded to the path.