Rule syntax and structure in Firebase - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Firebase Rule Match Statements

Which of the following Firebase security rule match statements correctly matches all documents in the 'users' collection?

A match /users/{userId} { allow read, write: if request.auth != null; }

B match /users { allow read, write: if request.auth != null; }

C match /users/{userId}/profile { allow read, write: if request.auth != null; }

D match /users/{userId}/documents/{docId} { allow read, write: if request.auth != null; }

💡 Hint

Remember that to match documents inside a collection, you need to specify a wildcard for document IDs.

The correct match statement to cover all documents in the 'users' collection uses a wildcard {userId} to represent any document ID inside 'users'. Option A correctly uses match /users/{userId}.

Option A matches the collection itself, not documents inside it. Option A matches a subcollection 'profile' inside each user document, which is more specific. Option A matches documents inside a subcollection 'documents' under each user, which is also more specific.

❓ Configuration

intermediate

Evaluating Firebase Rule Condition Syntax

Which of the following Firebase rule conditions correctly checks if the authenticated user's ID matches the document ID being accessed?

A allow read: if request.auth.uid == resource.data.uid;

B allow read: if request.auth.uid == resource.data.userId;

C allow read: if request.auth.uid == request.resource.id;

D allow read: if request.auth.uid == resource.id;

💡 Hint

The document's data field that stores the user ID must be referenced correctly.

The correct way to check if the authenticated user matches the document owner is to compare request.auth.uid with the user ID stored inside the document data, typically in a field like uid. Option A does this correctly.

Option A compares with resource.id, which is the document ID, not necessarily the user ID. Option A compares with resource.data.userId, which might be correct if the field is named 'userId', but the question implies the field is 'uid'. Option A uses request.resource.id, which is the ID of the document being written in the request, not the existing document.

❓ Architecture

advanced

Designing Firebase Rules for Nested Collections

You have a Firestore database with a collection 'projects' and each project has a subcollection 'tasks'. Which rule structure correctly allows authenticated users to read and write only their own projects and tasks?

A match /projects/{projectId} { allow read, write: if request.auth.uid == resource.data.ownerId; } match /projects/{projectId}/tasks/{taskId} { allow read, write: if request.auth.uid == resource.data.ownerId; }

B } ;dIrenwo.atad.ecruoser == diu.htua.tseuqer fi :etirw ,daer wolla { }dIksat{/sksat/}dItcejorp{/stcejorp/ hctam } ;dIrenwo.atad.ecruoser == diu.htua.tseuqer fi :etirw ,daer wolla { }dItcejorp{/stcejorp/ hctam

C match /projects/{projectId} { allow read, write: if request.auth.uid == resource.data.ownerId; } match /projects/{projectId}/tasks/{taskId} { allow read, write: if request.auth.uid == resource.data.assigneeId; }

D match /projects/{projectId} { allow read, write: if request.auth.uid == resource.data.ownerId; } match /projects/{projectId}/tasks/{taskId} { allow read, write: if request.auth.uid == resource.data.taskOwnerId; }

💡 Hint

Tasks may be assigned to different users than the project owner.

Option C correctly allows project owners to access their projects and allows task assignees to access their tasks. The project rule checks ownerId, and the task rule checks assigneeId, which reflects typical ownership and assignment.

Options B and C incorrectly check ownerId for tasks, which may block legitimate assignees. Option C uses a non-standard field taskOwnerId which may not exist.

❓ security

advanced

Identifying Security Risks in Firebase Rules

Consider the following Firebase rule snippet:

match /posts/{postId} { allow read: if true; allow write: if request.auth != null; }

What is the main security risk with this rule?

Firebase

match /posts/{postId} { allow read: if true; allow write: if request.auth != null; }

A Only authenticated users can read and write posts, so no risk exists.

B Anyone can read all posts, but only authenticated users can write, which may allow unauthorized edits.

C No one can read posts because read is set to true incorrectly.

D The rule syntax is invalid and will cause a deployment error.

💡 Hint

Check who can read and who can write with these conditions.

The rule allows anyone (even unauthenticated users) to read all posts because allow read: if true; means no restriction. However, only authenticated users can write. This means anyone can see all posts, which might be intended, but it also means unauthorized users can read sensitive data if posts are private.

Option B is wrong because read is open to all, not just authenticated users. Option B is wrong because if true allows all reads. Option B is wrong because the syntax is valid.

❓ service_behavior

expert

Predicting Firebase Rule Evaluation Outcome

Given the following Firebase rule snippet:

match /documents/{docId} { allow read: if request.time < timestamp.date(2023, 1, 1); allow write: if request.auth.uid == resource.data.ownerId; }

If a user tries to read a document on February 1, 2023, what will happen?

Firebase

match /documents/{docId} { allow read: if request.time < timestamp.date(2023, 1, 1); allow write: if request.auth.uid == resource.data.ownerId; }

A The write request will be allowed if the user is the owner, regardless of the date.

B The read request will be allowed because the user is authenticated.

C The read request will cause a syntax error due to incorrect timestamp usage.

D The read request will be denied because the current time is after January 1, 2023.

💡 Hint

Focus on the read condition and the date comparison.

The read rule only allows reads before January 1, 2023. Since February 1, 2023 is after that date, the read request will be denied regardless of authentication.

Option D is incorrect because authentication does not override the time condition. Option D is about write requests, not read. Option D is incorrect because the timestamp usage is valid.

Practice

1. What is the main purpose of a match block in Firebase security rules?

easy

A. To create new collections automatically

B. To define user roles and permissions

C. To write data to the database

D. To specify which data paths the rules apply to

Solution

1. Step 1: Understand the role of match blocks

   The match block is used to specify the path in the database where the rules apply.

2. Step 2: Differentiate from other rule parts

   Other parts like allow control access, but match targets the data location.

3. Final Answer:

   To specify which data paths the rules apply to -> Option D

4. Quick Check:

   match = data path selector [OK]

Hint: Remember: match points to data location [OK]

Common Mistakes:

• Confusing match with allow
• Thinking match defines user roles
• Assuming match writes data

2. Which of the following is the correct syntax to allow read access to all users in a Firebase rule?

easy

A. allow read { true }

B. allow read: if true;

C. allow read = true;

D. allow read if (true)

Solution

1. Step 1: Recall correct allow syntax

   The correct syntax uses a colon and condition: allow read: if true;

2. Step 2: Check other options for syntax errors

   Options A, B, and D use incorrect symbols or missing keywords.

3. Final Answer:

   allow read: if true; -> Option B

4. Quick Check:

   Correct allow syntax uses colon and if [OK]

Hint: Use colon and 'if' for conditions in allow [OK]

Common Mistakes:

• Using '=' instead of ':'
• Omitting 'if' keyword
• Using braces instead of semicolon

3. Given the rule snippet:

match /posts/{postId} {
  allow read: if request.auth != null;
  allow write: if request.auth.uid == resource.data.authorId;
}

What happens if a logged-in user tries to write to a post they did NOT create?

medium

A. Write is denied because user is not the author

B. Write is allowed because user is logged in

C. Write is allowed only if postId matches user ID

D. Write is denied because read access is restricted

Solution

1. Step 1: Analyze write condition

   Write is allowed only if request.auth.uid == resource.data.authorId, meaning user must be the author.

2. Step 2: Apply condition to user not author

   If user is logged in but not the author, condition fails, so write is denied.

3. Final Answer:

   Write is denied because user is not the author -> Option A

4. Quick Check:

   Write allowed only for author = A [OK]

Hint: Check if user ID matches author ID for write [OK]

Common Mistakes:

• Assuming any logged-in user can write
• Confusing read and write conditions
• Ignoring resource data in condition

4. Identify the error in this Firebase rule snippet:

match /users/{userId} {
  allow read if request.auth.uid == userId;
  allow write: if request.auth.uid == userId;
}

medium

A. Missing colon after 'allow read'

B. Incorrect variable name 'userId'

C. Missing semicolon after 'allow write' condition

D. Using '==' instead of '=' in conditions

Solution

1. Step 1: Check syntax for 'allow' statements

   Each allow must have a colon before the condition, e.g., allow read: if ...;

2. Step 2: Identify missing colon

   The first line misses colon after allow read, causing syntax error.

3. Final Answer:

   Missing colon after 'allow read' -> Option A

4. Quick Check:

   Colon required after allow keyword [OK]

Hint: Always put colon after allow before condition [OK]

Common Mistakes:

• Omitting colon after allow
• Confusing '=' and '=='
• Forgetting semicolon at line end

5. You want to write a rule that allows users to read their own profile data but only write if their profile contains a non-empty 'name' field. Which rule snippet correctly enforces this?

hard

A. match /profiles/{userId} {
allow read: if request.auth.uid == userId;
allow write: if request.resource.data.name != "";
}

B. match /profiles/{userId} {
allow read: if request.auth.uid == userId;
allow write: if request.auth.uid == userId || request.resource.data.name != "";
}

C. match /profiles/{userId} {
allow read: if request.auth.uid == userId;
allow write: if request.auth.uid == userId && request.resource.data.name != "";
}

D. match /profiles/{userId} {
allow read: if true;
allow write: if request.auth.uid == userId && request.resource.data.name == "";
}

Solution

1. Step 1: Understand read condition

   Users can read only their own profile: request.auth.uid == userId.

2. Step 2: Understand write condition

   Write allowed only if user owns profile AND 'name' field is not empty: request.auth.uid == userId && request.resource.data.name != "".

3. Step 3: Check options for correct logic

   match /profiles/{userId} { allow read: if request.auth.uid == userId; allow write: if request.auth.uid == userId && request.resource.data.name != ""; } matches both conditions correctly; others use wrong logic or allow too much.

4. Final Answer:

   match /profiles/{userId} { allow read: if request.auth.uid == userId; allow write: if request.auth.uid == userId && request.resource.data.name != ""; } -> Option C

5. Quick Check:

   Use AND for ownership and non-empty name [OK]

Hint: Use AND (&&) to combine ownership and data checks [OK]

Common Mistakes:

• Using OR (||) instead of AND (&&)
• Allowing write without ownership check
• Checking for empty string incorrectly