MockRounds Logo

Firebase Firestore Security Rules Essentials Quiz Quiz

Explore the fundamentals of Firestore security rules with this quiz, designed to help you understand how to control access and protect your cloud database. Learn about rule structure, permissions, and best practices for securing Firestore data with real-world scenarios.

  1. Rule Structure

    Which line correctly starts a Firestore security rule for a collection named 'users'?

    1. route /users:id {
    2. collection users(*userId) {
    3. match /users/{userId} {
    4. path /users(userId) {

    Explanation: The 'match /users/{userId} {' statement correctly defines the path for rules targeting each document in the 'users' collection. 'route /users:id {' and 'path /users(userId) {' are not valid syntax in Firestore rule definitions. 'collection users(*userId) {' uses incorrect syntax and will cause an error. Only 'match' is used to declare rule paths.

  2. Basic Read Permissions

    To allow anyone to read documents in the 'posts' collection but restrict write access, which rule is appropriate?

    1. allow all: if true;
    2. match /posts/{postId} { allow write: if true; }
    3. match /posts/{postId} { allow read: if true; allow write: if false; }
    4. match /posts/{postId} { allow get: if false; allow put: if true; }

    Explanation: The correct answer uses 'allow read: if true;' to permit all reads and 'allow write: if false;' to deny writes. 'allow get' and 'allow put' do not accurately describe Firestore operations. 'allow all: if true;' is not valid syntax. Allowing 'write' without restriction would let anyone modify data, which is not desired here.

  3. Document ID Wildcards

    In the rule 'match /items/{itemId} { ... }', what does '{itemId}' represent?

    1. A wildcard that matches any document ID in the 'items' collection
    2. The top-level database name
    3. Only documents where the ID equals 'itemId'
    4. A required fixed document named 'itemId'

    Explanation: '{itemId}' serves as a wildcard, allowing the rule to apply to any document in the 'items' collection regardless of its specific ID. It does not refer to the database name or require documents to be named 'itemId'. The rule is not restricted to documents with the ID literally set as 'itemId', but works for any document under '/items/'.

  4. Authentication Checks

    To permit only authenticated users to read a collection, which condition should be used?

    1. if request.token.exists
    2. if auth.present
    3. if request.auth != null
    4. if read.auth == true

    Explanation: The condition 'if request.auth != null' checks that a user is authenticated before granting access. 'if request.token.exists' is not valid Firestore syntax. 'if read.auth == true' and 'if auth.present' use incorrect property names and would not function as intended. Only 'request.auth' is the built-in way to refer to authentication data.

  5. Allowing Both Reads and Writes

    Which statement grants both read and write access within rules?

    1. allow read, write: if condition;
    2. enable access: if valid;
    3. permit all: if allowed;
    4. accept get, set: if true;

    Explanation: 'allow read, write: if condition;' is the correct syntax to grant both read and write permissions based on a condition. The phrases 'accept get, set: if true;', 'enable access: if valid;', and 'permit all: if allowed;' are not recognized statements in Firestore rules and would cause syntax errors.

  6. Valid Operations

    Which of the following is NOT a valid Firestore security rule operation?

    1. list
    2. update
    3. put
    4. delete

    Explanation: Firestore security rules recognize operations like 'update', 'delete', and 'list', but 'put' is not a valid operation. 'Update' refers to modifying existing documents, while 'delete' allows removing them. 'List' grants permission to retrieve multiple documents. 'Put' does not apply to Firestore rule operations.

  7. Access Control by Field Value

    In a rule, how can you restrict writing to a document only if a 'role' field equals 'admin'?

    1. allow write: if resource.data.role == 'admin';
    2. allow write: if input.role = admin;
    3. allow write: when data.role:admin;
    4. allow write: if resource.value.role != admin;

    Explanation: The correct way is to use 'allow write: if resource.data.role == 'admin';', which checks the document's field value. 'allow write: if input.role = admin;' mixes up the syntax and operators. 'allow write: when data.role:admin;' is not valid syntax. 'allow write: if resource.value.role != admin;' uses the wrong property and the wrong comparison.

  8. Read-Only Collections

    What is the effect of setting 'allow write: if false;' on a collection's rules?

    1. Documents can be written to only by admins
    2. Only read operations are denied
    3. All users can still add new documents but can't update old ones
    4. No documents in the collection can be created, updated, or deleted

    Explanation: 'allow write: if false;' blocks all write operations, meaning no user can create, update, or delete documents in that collection. It does not permit admin-only access unless another rule says so. It does not permit creation of new documents and blocks all write actions, not just updates. It does not affect read operations, only write.

  9. Rules Evaluation Order

    If multiple rules match a request, how does Firestore security determine access?

    1. All rules must allow the request
    2. The most specific matching rule is applied
    3. Whichever rule allows access wins
    4. The first rule written in the file applies

    Explanation: Firestore security rules evaluate all matches and apply the most specific rule relevant to the requested path. It does not simply pick the first rule in the file, nor does it require all rules to allow access. In case of conflicts, the specific match determines the outcome, not the one that simply allows access.

  10. Default Deny Behavior

    What happens if there is no matching allow statement for a Firestore operation?

    1. The database throws a syntax error
    2. The request is always allowed
    3. The request is denied by default
    4. The operation is delayed for review

    Explanation: If no allow rule matches a user's request, the default behavior is to deny access. There is no automatic approval or delayed review process. A syntax error only occurs if the security rules themselves are incorrectly written. Denial by default follows the principle of least privilege and protects data from unauthorized access.

mockrounds.com Learn • Practice • Evaluate