Role-based access control pattern in Firebase - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Role Assignment in Firebase Security Rules

In Firebase Security Rules, roles are often assigned to users to control access. Which of the following best describes how roles are typically stored and checked in Firebase?

A Roles are stored as custom claims in the user's authentication token and checked in security rules.

B Roles are stored in Firestore documents and automatically enforced by Firebase without rules.

C Roles are assigned by Firebase automatically based on user email domains.

D Roles are stored in client-side local storage and verified by security rules.

💡 Hint

Think about where Firebase stores user-specific metadata securely for access control.

Firebase uses custom claims in the authentication token to store roles securely. Security rules then check these claims to allow or deny access.

❓ Configuration

intermediate

Firebase Security Rule for Admin Role Access

Given a Firebase Firestore collection named projects, which security rule snippet correctly allows only users with the admin role to read documents?

Firebase

match /projects/{projectId} {
  allow read: if request.auth.token.role == 'admin';
}

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

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

C allow read: if request.auth.token.roles.includes('admin');

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

💡 Hint

Check the exact property name and syntax used in Firebase security rules for custom claims.

Firebase stores custom claims under request.auth.token. The role is a string, so equality check with == is correct.

❓ Architecture

advanced

Designing Role-based Access Control with Firebase and Firestore

You want to implement a role-based access control system where users can have multiple roles stored in Firestore under users/{userId}/roles as an array. Which approach is best to enforce access control in Firebase Security Rules?

A Store roles in client-side code and pass them as request parameters to security rules.

B Store roles as custom claims in the auth token and check them directly in security rules.

C Read the roles array from Firestore in security rules using <code>get()</code> and check if it contains the required role.

D Use Firebase Functions to check roles and bypass security rules.

💡 Hint

Consider performance and security best practices for Firebase Security Rules.

Security rules cannot reliably or efficiently read Firestore data for every request. Custom claims in auth tokens are the recommended way to store roles for fast and secure checks.

❓ security

advanced

Preventing Privilege Escalation in Firebase RBAC

Which practice helps prevent users from escalating their privileges by modifying their roles in Firebase?

A Only allow role changes through secure backend functions with admin privileges.

B Store roles in client-side local storage and trust the client to enforce them.

C Allow users to update their roles directly in Firestore documents.

D Use Firestore rules to allow anyone to write to the roles collection.

💡 Hint

Think about who should have permission to change roles and how to enforce it securely.

Roles must be managed securely on the backend. Allowing clients to modify roles directly risks privilege escalation.

❓ service_behavior

expert

Effect of Custom Claims Update on Firebase Auth Tokens

After updating a user's custom claims to add a new role, what must happen for the new role to be recognized in Firebase Security Rules?

A The Firestore database must be manually refreshed to sync roles.

B The new claims are immediately available without any user action.

C The user must sign out and sign back in to refresh their ID token with updated claims.

D The client must call a special Firebase API to refresh claims automatically.

💡 Hint

Consider how Firebase ID tokens cache custom claims and when they update.

Firebase ID tokens cache custom claims at sign-in. To get updated claims, the user must sign out and sign back in or force token refresh.

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