1
votes

I am creating a react native application using Firestore and I am not sure how to implement secure schema validation on document creation and update.

If I understand security rules, it is possible to:

  • Limit who can perform operations (update, read, write, etc.) on documents
  • Limit operations allowed based on field conditionals
  • Limit operations allowed based on custom functions (post w/ examples)

My concern is that because of the client side nature of the requests, a savvy user could utilize their authentication and some client side code to .set() any field or map/object to any value they want unless a security rule prevents it. It appears I could use very complicated custom functions to validate the data received. I could also validate every update and create through a Cloud Function API, but I am attempting to use the Firestore database itself whenever possible.

Am I right to be concerned about the potential for users to abuse their .set() field creation abilities on authorized documents (i.e. documents with minimal userId rules)?

Is there an accepted way to create security rules that prevent client abuse of documents that don't have custom functions that validate the schema?

2
@FrankvanPuffelen Just to clarify, from your responses below it sounds like "security rule custom functions", or "cloud functions" are the only way to validate and secure the database? is that correct?Jason
There might be other/better options, depending on what you want to do. But the idiomatic ways to prevent abuse are through rules, through Functions, or through a combination of those.Frank van Puffelen

2 Answers

2
votes

You should always consider malicious users, and how they might affect your data, no matter whether you write the validation in security rules or in more traditional code in Cloud Functions.

Compare these two statements from your question:

  1. "I could use very complicated custom functions to validate the data received"
  2. "I could also validate every update and create through a Cloud Function API"

In both cases you're writing custom code to ensure the data the user enters is valid according to your business rules. Since these rules are specific to your business, there's no way to prevent you having to write them. The only difference is where you write these business rules. With Cloud Functions you're writing the validations in regular JavaScript code, in an environment you may already be familiar with. With security rules you're writing the validations in a domain-specific language, which you'll have to learn.

I personally far prefer writing my business rules into Firestore's server-side security rule language, and then use Cloud Functions for implementing business logic on top of that validated data.

2
votes

If you are worried that user might just reverse engineer your app and mess up your code to harm your database, then yes this is possible. You should have proper rules set. Talking of updating data in database from app, try to update it through cloud functions as far as possible. This way you might need to give less access to your users to the database directly.

You can check my answer here. This will help you setting rules and some ways to code adapt your app code based on situation. The answer also has some lines on where can one use cloud functions to reduce direct contact with the database.

And if there is no know or you feel the information should be directly updated to the database, change your rules to this: ".write": "$uid === auth.uid" . Here $uid is name of parent node and can be anything else. This way a user can access his/her data only and even if the user modifies your app, they can harm their data only. (You should have correct rules set).

You can check out this link for most of the rules combinations.

And do check the answer whose link is above. That might clarify how it will secure your database to some extent. If you can provide any particular situation regarding your app and want some information for how to set rules there, feel free to drop a comment :-)