Testing rules with emulator in Firebase - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

What happens when you run a Firestore read with the emulator and rules deny access?

You have Firestore security rules that deny read access to a document. You run a read request using the Firebase emulator. What is the expected behavior?

A The emulator returns a network timeout error.

B The emulator returns the document data ignoring the rules.

C The emulator returns a permission denied error immediately.

D The emulator crashes and stops responding.

💡 Hint

Think about how the emulator enforces rules like the real service.

The Firebase emulator enforces security rules exactly as the real Firestore service does. If rules deny access, the emulator returns a permission denied error immediately.

❓ Configuration

intermediate

Which command starts the Firebase emulator with Firestore and Authentication?

You want to start the Firebase emulator locally with Firestore and Authentication emulators enabled. Which command is correct?

A firebase emulators:start --only firestore,auth

B firebase start emulators --services firestore auth

C firebase emulators:run firestore auth

D firebase emulator:start firestore auth

💡 Hint

Check the official Firebase CLI command syntax for starting emulators.

The correct command is firebase emulators:start --only firestore,auth. It starts only the Firestore and Authentication emulators.

❓ Architecture

advanced

How does the Firebase emulator suite help in testing security rules before deployment?

Choose the best description of how the Firebase emulator suite supports testing security rules before deploying to production.

A It automatically fixes security rule errors and deploys corrected rules to production.

B It simulates the backend services locally, enforcing security rules so you can test reads and writes without affecting live data.

C It only tests client-side code without enforcing any security rules.

D It replaces the production database with a copy for testing.

💡 Hint

Consider how local emulation helps avoid risks to live data.

The Firebase emulator suite runs backend services locally and enforces security rules, allowing safe testing of reads and writes without touching production data.

❓ security

advanced

What is the effect of disabling rules validation in the Firebase emulator?

If you disable rules validation in the Firebase emulator, what happens when you perform a read or write operation?

A All reads and writes succeed regardless of security rules.

B The emulator throws an error and stops running.

C The emulator ignores all requests and returns empty responses.

D Reads succeed but writes fail with permission denied.

💡 Hint

Think about what disabling rules validation means for security enforcement.

Disabling rules validation causes the emulator to allow all reads and writes without checking security rules, which can be useful for testing but unsafe for real use.

✅ Best Practice

expert

Which practice ensures reliable testing of Firestore rules using the emulator in a CI/CD pipeline?

To reliably test Firestore security rules in a continuous integration/continuous deployment (CI/CD) pipeline using the Firebase emulator, which practice is best?

A Use the emulator only locally and skip tests in CI/CD.

B Deploy rules directly to production and run tests against live Firestore.

C Run tests without starting the emulator, relying on cached rules.

D Start the emulator in a clean environment, run rule tests with the Firebase Testing SDK, then shut down the emulator.

💡 Hint

Consider how to isolate tests and avoid side effects in automated pipelines.

Starting the emulator fresh in CI/CD, running tests with the Firebase Testing SDK, and shutting down ensures isolated, repeatable tests without affecting production.

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