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.