Testing rules with emulator in Firebase - Commands & Configuration

Introduction

When you build apps that store data in Firebase, you need to protect that data with rules. Testing these rules before going live helps avoid mistakes that could let anyone read or change your data. The Firebase emulator lets you safely test your rules on your computer without affecting real data.

When you want to check if your Firebase security rules allow only the right users to read or write data.

When you want to try changes to your rules without risking your live database.

When you want to simulate different user roles and see how rules behave for each.

When you want to run automated tests on your rules as part of your development process.

When you want to debug why a certain read or write is blocked or allowed.

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;
    }
  }
}

This file defines Firestore security rules.

rules_version sets the version of rules syntax.

service cloud.firestore means these rules apply to Firestore.

The match /users/{userId} block controls access to user documents.

It allows read and write only if the user is logged in and their ID matches the document ID.

Commands

Starts the Firestore emulator locally so you can test your rules without touching live data.

Terminal

firebase emulators:start --only firestore

Expected Output

i  emulators: Starting emulators: firestore

✔  firestore: Emulator started at http://localhost:8080



⚠  emulators: The UI is not running because it is not enabled in firebase.json



✔  All emulators started, it is now safe to connect.

→

--only firestore - Starts only the Firestore emulator without other Firebase emulators.

Runs tests against your Firestore rules using the emulator to check if your rules work as expected.

Terminal

firebase emulators:exec "firebase firestore:rules:test --rules firestore.rules --project demo-project --test-file firestore.test.json"

Expected Output

✔  Running Firestore rules tests from firestore.test.json...

Tests completed: 5

Passed: 5

Failed: 0

→

--rules - Specifies the rules file to test.

→

--project - Specifies the Firebase project ID for the test context.

Runs a set of predefined tests from a JSON file against your Firestore rules to verify access control.

Terminal

firebase firestore:rules:test --rules firestore.rules --project demo-project --test-file firestore.test.json

Expected Output

✔  Running Firestore rules tests from firestore.test.json...

Tests completed: 5

Passed: 5

Failed: 0

→

--test-file - Specifies the JSON file containing test cases.

Key Concept

If you remember nothing else from this pattern, remember: always test your Firebase security rules locally with the emulator before deploying to protect your data.

Common Mistakes

Running tests without starting the emulator first

The tests need the emulator running to simulate the database environment; otherwise, they fail or give wrong results.

Always start the Firestore emulator with 'firebase emulators:start --only firestore' before running rule tests.

Using incorrect project ID in test commands

The emulator uses the project ID to simulate the environment; a wrong ID can cause tests to run against wrong settings or fail.

Use the correct Firebase project ID in the '--project' flag matching your local setup.

Not specifying the rules file in test commands

Without specifying the rules file, tests run against default or old rules, missing your latest changes.

Always use the '--rules' flag to point to your current rules file.

Summary

Start the Firestore emulator locally to safely test your security rules.

Run rule tests using the emulator to verify who can read or write data.

Use the correct project ID and rules file when running tests to ensure accuracy.

Practice

1. What is the main purpose of using the Firebase emulator when testing Firestore security rules?

easy

A. To safely test rules without affecting live data

B. To deploy rules directly to production

C. To speed up Firestore queries in production

D. To backup Firestore data automatically

Solution

1. Step 1: Understand the role of the emulator

   The Firebase emulator creates a safe environment that mimics Firestore without touching live data.

2. Step 2: Identify the benefit of safe testing

   This allows developers to test security rules without risking data loss or exposure in production.

3. Final Answer:

   To safely test rules without affecting live data -> Option A

4. Quick Check:

   Emulator = Safe testing environment [OK]

Hint: Emulator means safe testing, no live data risk [OK]

Common Mistakes:

• Thinking emulator deploys rules to production
• Confusing emulator with data backup tool
• Assuming emulator speeds up production queries

2. Which command correctly starts only the Firestore emulator?

easy

A. firebase start firestore

B. firebase emulators:start --only firestore

C. firebase emulators:run firestore

D. firebase firestore:start

Solution

1. Step 1: Recall the correct Firebase CLI command

   The command to start emulators selectively uses 'firebase emulators:start --only' followed by the service name.

2. Step 2: Match the command to Firestore emulator

   For Firestore only, the command is 'firebase emulators:start --only firestore'.

3. Final Answer:

   firebase emulators:start --only firestore -> Option B

4. Quick Check:

   Correct CLI syntax = firebase emulators:start --only firestore [OK]

Hint: Use --only with service name to start specific emulator [OK]

Common Mistakes:

• Using 'firebase start firestore' which is invalid
• Confusing 'run' with 'start' in command
• Omitting '--only' flag

3. Given this Firestore security rule snippet tested in the emulator:

service cloud.firestore {
  match /databases/{database}/documents {
    match /messages/{msgId} {
      allow read: if request.auth != null;
      allow write: if false;
    }
  }
}

What will happen if an unauthenticated user tries to read a message?

medium

A. Read is denied

B. Write is allowed

C. Read is allowed

D. Write is denied

Solution

1. Step 1: Analyze the read rule condition

   The rule allows read only if request.auth is not null, meaning user must be authenticated.

2. Step 2: Check the user's authentication status

   The user is unauthenticated, so request.auth is null, failing the condition.

3. Final Answer:

   Read is denied -> Option A

4. Quick Check:

   Unauthenticated read = denied [OK]

Hint: Read allowed only if user is authenticated [OK]

Common Mistakes:

• Assuming read is allowed without authentication
• Confusing read and write permissions
• Ignoring the request.auth check

4. You wrote this rule in the emulator but all writes are failing:

allow write: if request.auth.uid == userId;

What is the likely error causing the failure?

medium

A. request.auth.uid is always null in emulator

B. Emulator does not support write rules

C. Write rules cannot use '==' operator

D. The variable 'userId' is not defined in the rule context

Solution

1. Step 1: Check the rule variable usage

   The rule compares request.auth.uid to userId, but userId is not defined or extracted from the document path or data.

2. Step 2: Understand rule variable scope

   Variables like userId must be defined in the path or request data; otherwise, the condition fails.

3. Final Answer:

   The variable 'userId' is not defined in the rule context -> Option D

4. Quick Check:

   Undefined variable causes rule failure [OK]

Hint: Ensure all variables in rules are properly defined [OK]

Common Mistakes:

• Assuming emulator nullifies request.auth.uid
• Thinking '==' is invalid in rules
• Believing emulator ignores write rules

5. You want to test that only users can write their own profile document in the emulator. The document path is /users/{userId}. Which rule correctly enforces this and can be tested in the emulator?

hard

A. allow write: if true;

B. allow write: if request.auth.uid != userId;

C. allow write: if request.auth.uid == userId;

D. allow write: if request.auth != null;

Solution

1. Step 1: Match userId from document path

   In rules, userId is a variable from the path /users/{userId} and can be used in conditions.

2. Step 2: Enforce write only if authenticated user matches userId

   The condition 'request.auth.uid == userId' ensures only the user can write their own profile.

3. Final Answer:

   allow write: if request.auth.uid == userId; -> Option C

4. Quick Check:

   User writes own doc = request.auth.uid == userId [OK]

Hint: Match auth uid to path userId for user-specific writes [OK]

Common Mistakes:

• Using '!=' instead of '==' causing wrong access
• Allowing any authenticated user to write all profiles
• Setting rule to always true, no security