Resource and request objects in Firebase - Commands & Configuration

Introduction

When building apps with Firebase, you often need to handle data and actions securely. Resource and request objects help you define what data is available and what actions users can perform. They make sure your app works correctly and safely.

When you want to control who can read or write data in your Firebase database.

When you need to check what data a user is sending before saving it.

When you want to respond differently based on the user's request details.

When you want to protect your app from unwanted or harmful data changes.

When you want to log or audit user actions on your Firebase resources.

Config File - firestore.rules

firestore.rules

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
    match /posts/{postId} {
      allow read: if true;
      allow write: if request.auth != null && request.resource.data.keys().hasAll(['title', 'content']) && request.resource.data.title is string && request.resource.data.content is string;
    }
  }
}

This file defines rules for Firestore database access.

rules_version: sets the version of rules syntax.

service cloud.firestore: targets Firestore database.

match /databases/{database}/documents: applies rules to all documents.

match /users/{userId}: allows only authenticated users to read/write their own user data.

match /posts/{postId}: allows anyone to read posts but only authenticated users can write posts with required fields 'title' and 'content' as strings.

request.auth: the user making the request.

request.resource.data: the data being written.

Commands

This command uploads and activates the Firestore security rules defined in the 'firestore.rules' file to your Firebase project.

Terminal

firebase deploy --only firestore:rules

Expected Output

=== Deploying to 'your-project-id'...



i  deploying firestore.rules

✔  firestore.rules: Rules deployed successfully



✔  Deploy complete!

→

--only firestore:rules - Deploys only Firestore security rules without affecting other Firebase services.

Starts the local Firestore emulator so you can test your rules and database behavior safely on your computer without affecting live data.

Terminal

firebase emulators:start --only firestore

Expected Output

i  emulators: Starting emulators: firestore

✔  firestore emulator running at http://localhost:8080



All emulators started, it is now safe to connect your app.

→

--only firestore - Starts only the Firestore emulator.

Fetches the document 'post1' from the 'posts' collection in the local Firestore emulator to verify read access.

Terminal

curl -X GET 'http://localhost:8080/v1/projects/your-project-id/databases/(default)/documents/posts/post1'

Expected Output

{

  "name": "projects/your-project-id/databases/(default)/documents/posts/post1",

  "fields": {

    "title": {"stringValue": "Hello World"},

    "content": {"stringValue": "This is a test post."}

  },

  "createTime": "2024-06-01T12:00:00.000Z",

  "updateTime": "2024-06-01T12:00:00.000Z"

}

Attempts to write a new document 'post2' to the 'posts' collection in the local Firestore emulator, testing write rules with required fields.

Terminal

curl -X PATCH 'http://localhost:8080/v1/projects/your-project-id/databases/(default)/documents/posts/post2' -H 'Content-Type: application/json' -d '{"fields": {"title": {"stringValue": "New Post"}, "content": {"stringValue": "Content here."}}}'

Expected Output

{

  "name": "projects/your-project-id/databases/(default)/documents/posts/post2",

  "fields": {

    "title": {"stringValue": "New Post"},

    "content": {"stringValue": "Content here."}

  },

  "createTime": "2024-06-01T12:05:00.000Z",

  "updateTime": "2024-06-01T12:05:00.000Z"

}

Key Concept

If you remember nothing else from this pattern, remember: resource and request objects let you control who can do what with your Firebase data and what data is allowed.

Common Mistakes

Trying to write data without required fields in request.resource.data.

The security rules reject writes missing required fields, causing the write to fail.

Always include all required fields with correct data types when writing data.

Allowing read or write access without checking request.auth.

This can expose or allow changes to data by anyone, risking security.

Always verify request.auth to restrict access to authenticated users as needed.

Deploying rules without testing them locally first.

Mistakes in rules can block legitimate access or allow unwanted access in production.

Use the Firebase emulator to test rules before deploying.

Summary

Write Firestore security rules using resource and request objects to control data access and validation.

Deploy rules with 'firebase deploy --only firestore:rules' to apply them to your project.

Test rules locally using the Firestore emulator and curl commands to simulate reads and writes.