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?
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.
Given a Firebase Firestore collection named projects, which security rule snippet correctly allows only users with the admin role to read documents?
match /projects/{projectId} {
allow read: if request.auth.token.role == 'admin';
}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.
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?
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.
Which practice helps prevent users from escalating their privileges by modifying their roles in Firebase?
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.
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?
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.