Role-based access control pattern in Firebase - Commands & Configuration

Introduction

Role-based access control helps you decide who can do what in your app. It solves the problem of keeping your app safe by giving different permissions to different users based on their role.

When you want only admins to add or delete data in your Firebase database.

When you want regular users to read data but not change it.

When you want to restrict access to certain parts of your app based on user roles.

When you want to manage permissions easily without writing complex checks everywhere.

When you want to keep your app secure by limiting what users can do.

Config File - firestore.rules

firestore.rules

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    function isSignedIn() {
      return request.auth != null;
    }

    function isAdmin() {
      return request.auth != null && request.auth.token.role == 'admin';
    }

    match /{document=**} {
      allow read: if isSignedIn();
      allow write: if isAdmin();
    }
  }
}

This file sets rules for who can read and write data in Firestore.

allow read: lets any signed-in user read data.

allow write: only lets users with the 'admin' role write data.

isSignedIn() checks if the user is logged in.

isAdmin() checks if the user is logged in and has the admin role in their token.

Commands

This command uploads and activates the Firestore security rules to your Firebase project. It ensures your role-based access control is enforced.

Terminal

firebase deploy --only firestore:rules

Expected Output

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



i  deploying firestore

i  firestore: releasing rules...

✔  firestore: rules released 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 security rules and role-based access control 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.

Runs tests against your Firestore rules using a test file to check if role-based access control works as expected.

Terminal

firebase firestore:rules:test --rules=firestore.rules --file=tests.json

Expected Output

Running Firestore rules tests...

Test 1: Read by signed-in user - PASSED

Test 2: Write by admin user - PASSED

Test 3: Write by regular user - FAILED



3 tests run, 2 passed, 1 failed

→

--rules - Specifies the rules file to test.

→

--file - Specifies the test cases file.

Key Concept

If you remember nothing else from this pattern, remember: assign roles in user tokens and enforce permissions in Firestore rules.

Common Mistakes

Not including role information in the user's authentication token.

Without role data, the rules cannot check permissions correctly, so access control fails.

Make sure to add the user's role to their auth token using Firebase Authentication custom claims.

Allowing write access to all signed-in users instead of only admins.

This lets unauthorized users change data, breaking security.

Use a function like isAdmin() in your rules to restrict write access only to admin roles.

Not testing rules locally before deploying.

Mistakes in rules can lock out users or expose data unintentionally.

Use the Firebase emulator and rules test commands to verify your access control before deploying.

Summary

Write Firestore security rules that check user roles in their auth token.

Deploy rules using 'firebase deploy --only firestore:rules' to enforce access control.

Test rules locally with the Firebase emulator and rules test commands to ensure correct permissions.

Practice

1. What is the main purpose of role-based access control (RBAC) in Firebase security rules?

easy

A. To store user data in Firestore

B. To manage user permissions based on their assigned roles

C. To create user authentication tokens

D. To automatically backup database data

Solution

1. Step 1: Understand RBAC concept

   RBAC assigns permissions to users based on their roles, controlling what they can access.

2. Step 2: Identify RBAC purpose in Firebase

   In Firebase, RBAC is used in security rules to allow or deny access depending on user roles.

3. Final Answer:

   To manage user permissions based on their assigned roles -> Option B

4. Quick Check:

   RBAC controls permissions by roles [OK]

Hint: RBAC controls access by user roles, not data storage [OK]

Common Mistakes:

• Confusing RBAC with data storage functions
• Thinking RBAC creates authentication tokens
• Assuming RBAC handles backups

2. Which Firebase security rule syntax correctly checks if a user has the role 'admin' using request.auth.token.role?

easy

A. allow read: if request.auth.token.role == 'admin';

B. allow read: if request.auth.role == 'admin';

C. allow read: if auth.token.role == 'admin';

D. allow read: if request.auth.token == 'admin';

Solution

1. Step 1: Identify correct token path

   The user's role is stored in request.auth.token.role, so the check must use this exact path.

2. Step 2: Match syntax for role check

   The correct syntax compares request.auth.token.role to the string 'admin' using ==.

3. Final Answer:

   allow read: if request.auth.token.role == 'admin'; -> Option A

4. Quick Check:

   Use full path request.auth.token.role == 'admin' [OK]

Hint: Use full path request.auth.token.role for role checks [OK]

Common Mistakes:

• Using request.auth.role instead of request.auth.token.role
• Omitting 'token' in the path
• Comparing token object directly to string

3. Given this Firebase rule snippet:

allow write: if request.auth.token.role == 'editor';

What happens if a user with role 'viewer' tries to write data?

medium

A. The write is allowed because the user is authenticated

B. The write is allowed only if the user has a custom claim

C. The write is denied because the role is not 'editor'

D. The write is denied because the token is missing

Solution

1. Step 1: Analyze the rule condition

   The rule allows write only if request.auth.token.role equals 'editor'.

2. Step 2: Check user's role against condition

   The user has role 'viewer', which does not match 'editor', so the condition fails.

3. Final Answer:

   The write is denied because the role is not 'editor' -> Option C

4. Quick Check:

   Role mismatch denies write [OK]

Hint: Role must exactly match to allow access [OK]

Common Mistakes:

• Assuming any authenticated user can write
• Confusing roles with authentication status
• Ignoring role check in rules

4. Identify the error in this Firebase security rule snippet:

allow read: if request.auth.token.role = 'admin';

medium

A. Using single equals '=' instead of double equals '==' for comparison

B. Missing semicolon at the end of the statement

C. Incorrect property name; should be request.auth.role

D. Using 'allow read' instead of 'allow write'

Solution

1. Step 1: Check comparison operator

   The rule uses '=' which is an assignment operator, not a comparison operator.

2. Step 2: Correct operator for equality check

   Firebase rules require '==' to compare values, so '=' causes a syntax error.

3. Final Answer:

   Using single equals '=' instead of double equals '==' for comparison -> Option A

4. Quick Check:

   Use '==' for comparisons in rules [OK]

Hint: Use '==' for comparisons, '=' is assignment [OK]

Common Mistakes:

• Using '=' instead of '==' in conditions
• Confusing property names in request.auth
• Ignoring syntax errors in rules

5. You want to allow users with roles 'admin' or 'moderator' to delete documents, but only 'admin' can update them. Which Firebase rule snippet correctly implements this?

hard

A. allow delete: if request.auth.token.role == 'admin' || 'moderator';
allow update: if request.auth.token.role == 'admin';

B. allow delete, update: if request.auth.token.role == 'admin' || 'moderator';

C. allow delete: if request.auth.token.role == 'admin' && request.auth.token.role == 'moderator';
allow update: if request.auth.token.role == 'admin';

D. allow delete: if request.auth.token.role in ['admin', 'moderator'];
allow update: if request.auth.token.role == 'admin';

Solution

1. Step 1: Understand role conditions for delete

   Users with role 'admin' or 'moderator' can delete, so use 'in' operator with list ['admin', 'moderator'] for clarity and correctness.

2. Step 2: Understand role condition for update

   Only 'admin' can update, so check equality with 'admin' for update permission.

3. Step 3: Evaluate options

   allow delete: if request.auth.token.role == 'admin' || 'moderator'; allow update: if request.auth.token.role == 'admin'; has syntax error ('|| 'moderator'' invalid); allow delete, update: if request.auth.token.role == 'admin' || 'moderator'; has syntax error with '|| 'moderator''; allow delete: if request.auth.token.role == 'admin' && request.auth.token.role == 'moderator'; allow update: if request.auth.token.role == 'admin'; uses '&&' which requires both roles simultaneously (impossible). allow delete: if request.auth.token.role in ['admin', 'moderator']; allow update: if request.auth.token.role == 'admin'; correctly uses 'in' and separate rules.

4. Final Answer:

   allow delete: if request.auth.token.role in ['admin', 'moderator']; allow update: if request.auth.token.role == 'admin'; -> Option D

5. Quick Check:

   Use 'in' for multiple roles, '==' for single role [OK]

Hint: Use 'in' for multiple roles, '==' for single role check [OK]

Common Mistakes:

• Using '&&' instead of '||' for multiple roles
• Incorrect syntax with '||' and strings
• Trying to check multiple roles with '==' operator