Mark Sonn
Mark Sonn

Reputation: 848

Firestore security rules: do undefined object properties matter?

I was wondering what the convention was with regard to undefined properties with firestore security rules.

For example in the following rule that checks a custom claim:

allow read: if request.auth.token.claims.admin;

There are many points for an undefined property error, by far the most likely being if a user is not authenticated then request.auth will be undefined, so request.auth.token.claims.admin will be trying to access a property of an undefined value.

I have noticed that in the documentation request.auth.uid is a common check and they don't check if request.auth is defined first. However, in my research I noticed that some people do perform the check for similar queries, for example in this stack overflow answer.

Below is an annotated screenshot of what the simulator returns. My understanding is that this check for undefined properties is not necessary for security. My question is rather what the standard is and if not checking for undefined properties is the standard then why does the simulator throw an error?

enter image description here

On a side note which of the following (implicit or explicit boolean conditions) is preferred and why:

allow read: if request.auth.token.claims.admin;

allow read: if request.auth.token.claims.admin == true;

Upvotes: 2

Views: 1542

Answers (1)

Doug Stevenson
Doug Stevenson

Reputation: 317750

Firstly: All errors in rules evaluation result in an error. An error, without any conditioning, results in a rejection of access. So, if you try to access a property of a null or undefined object, that's an error (since that property doesn't exist), and results in an immediate rejection of access.

If you want to explicitly check for null in your rules, that's fine. That likely helps the readability of those rules. But you're not obliged to do so because of the immediate rejection of the access. It's entirely up to you.

Upvotes: 4

Related Questions