Resource and request objects in Firebase - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

What is the output of this Firebase Firestore security rule evaluation?

Given the following Firestore security rule snippet, what will be the result of a read request if the document's field ownerId matches the request.auth.uid?

Firebase

service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read: if resource.data.ownerId == request.auth.uid;
    }
  }
}

A The read request is allowed only if the userId path variable matches request.auth.uid.

B The read request is always allowed regardless of the authenticated user.

C The read request is denied because resource.data is not accessible in read rules.

D The read request is allowed only if the authenticated user's ID matches the document's ownerId.

💡 Hint

Remember that resource.data refers to the existing document data and request.auth.uid is the authenticated user's ID.

The rule allows read access only if the document's ownerId field matches the authenticated user's ID. This ensures users can only read their own documents.

🧠 Conceptual

intermediate

Which Firebase request object property contains the data sent by the client in a write operation?

In Firebase security rules, when a client tries to write data, which property of the request object holds the new data the client wants to write?

A request.resource.data

B request.data

C request.auth.token

D request.writeData

💡 Hint

Think about the difference between resource and request.resource.

request.resource.data contains the data the client wants to write. resource.data is the existing data before the write.

❓ Architecture

advanced

Which Firebase security rule correctly restricts document deletion to the document owner only?

You want to allow only the owner of a document to delete it. The document has a field ownerId. Which rule correctly enforces this?

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

B allow delete: if request.resource.data.ownerId == request.auth.uid;

C allow delete: if request.auth.uid != resource.data.ownerId;

D allow delete: if request.auth.token.owner == resource.data.ownerId;

💡 Hint

Remember that resource.data is the current document data before deletion.

For deletion, resource.data holds the existing document data. The rule checks if the authenticated user is the owner.

❓ security

advanced

What error occurs if you try to access resource.data in a create request where the document does not exist yet?

In a Firestore security rule for a create operation, what happens if you try to read resource.data?

A It returns the data being created from <code>request.resource.data</code>.

B It causes a runtime error because <code>resource.data</code> is undefined on create.

C It returns null because the document does not exist yet.

D It returns an empty map {}.

💡 Hint

Think about the difference between existing data and new data during create.

On create, resource.data is null because the document does not exist yet. Accessing it returns null, not an error.

✅ Best Practice

expert

Which Firebase security rule snippet best prevents unauthorized updates to a user's email field?

You want to allow users to update their documents but prevent them from changing the email field. Which rule snippet enforces this correctly?

A allow update: if request.auth.uid == resource.data.ownerId && request.resource.data.email == request.auth.token.email;

B allow update: if request.resource.data.email == resource.data.email;

C allow update: if request.resource.data.email != resource.data.email;

D allow update: if request.auth.uid == resource.data.ownerId;

💡 Hint

Compare the new email field with the existing one to detect changes.

Option B ensures the email field is unchanged during update, preventing unauthorized modifications.