Why You should not Write Strict Data Validation in Firestore Security Rules

Have you ever been to a castle in Japan? Osaka Castle, a very famous castle, is said to have possessed a double moat for defense. It must have taken a lot of effort and cost to create so many moats.

Now, Firestore, like a castle, needs protection from outside forces. In Firestore, this protection is provided using Firestore Security Rules. So, how much protection should be included in Firestore Security Rules? Should it have strict data validation like the double moats of Osaka Castle?

In conclusion, in my experience, Firestore Security Rules should not include strict data validation. Now let’s consider the reasons why.

Reasons

1. The upper limit of the number of expressions to evaluate

It may surprise you to know that Firestore Security Rules sets an upper limit of 1000 on the number of expressions that can be evaluated. So if you write a lot of rigorous data validation, you may reach the limit very quickly.

In my experience, as soon as I did a rigorous data validation of an object with only 40-50 properties in total, I encountered the following error.

maximum of 1000 expressions to evaluate has been reached

So, when building a system to some extent, it is impossible to do rigorous data validation on all the data.

2. Duplicate verification

A friendly user interface shows the user what is wrong with the input in a clear way. In order to do so, data validation must be performed on the user interface side as well. If strict data validation is done on the Firestore Security Rules side, it would be a duplicate check and could cause many problems( costs, bugs, etc ).

3. Difficult to find the cause of the error

The error message for Firestore Security Rules looks like this.

FirebaseError: 7 PERMISSION_DENIED: false for ‘update’ @ L541, false for ‘update’ @ L599

Very unfriendly. The number of lines displayed only points to the location of the match statement. Since complex validation rules are usually written separately for each function, this information is not useful. The more complex data validation you write, the more you’ll get bogged down in the mire of cause-finding.

How should we view Security Rules?

It is important not to lose sight of its purpose. What are the Firestore Security Rules for? Firestore can be accessed directly by the user. So we must prevent malicious users from accessing other users’ data or destroying the database. This is the main purpose of the Firestore Security Rules!

When you think about it, isn’t the security of the data more important than the validity of the data?

Even if inconsistent data is created by a malicious user as his own data, it is almost always the malicious user himself who suffers. However, very large data can destroy the database and must be prevented by security rules. This is the difference between validity and security.

So, in most cases, your security rules should only need to check the following two things.
1. if the user has permission to access the data
2. if the user is trying to register a larger-than-expected amount of data

In fact, at first, I wrote very intricate data validation logic in my security rules. But as a result of arriving at this idea, I rewrote many data validation functions into safety check functions.

// Before
function isValidAccount(data){
  return
    data.size() == 2
    && 'email' in data && data.email is string
    // Many expressions to validate email here
    // :
    // :
   && 'name' in data && data.name is string
    // Many expressions to validate name here
    // :
    // :
}

// After
function isSafetyAccount(data){
  return  
    data.size() == 2
    && 'email' in data && data.email is string 
        && data.email.length < 100
    && 'name' in data && data.name is string 
        && data.name.length < 100
}

Conclusion

More than enough is too much. Overly strict Firestore Security Rules can be harmful but not beneficial. There is no need to create a useless moat. So think carefully about the role of the rules and write appropriate ones.

I hope this article will be useful to someone. 😊