A List of Firestore Security Rules for Your Firebase Project
Security is the most important part of a database. If you don’t properly secure your database, then the data inside is just waiting to be stolen, corrupted, or completely wiped.
Firestore has some smart and straightforward security rules to help keep the database running safe and smooth. These rules decide what behaviors to allow for the client side.
Ideally, you want to double check all data on the client side, before it is uploaded to the database. But from time to time, you may run into a bug that is introducing wrong data into Firestore, or even worse, someone modifies your client app (whether it’s your mobile app, web app, or even a server-side component that calls Firebase’s REST API) and attempts to corrupt or steal the data in Firestore.
That’s why you always want to check requests on the database side as well.
Have in mind that Firestore rules do not apply to the Firebase Admin SDK, commonly used in Cloud Functions and other trusted environments.
List of Rules
This is a list of simple and complex Firebase Security rules that you can use in your project today. I hope you will find them helpful.
Allow only authenticated reads
Allow only Firebase authenticated users to read documents under the collection named documents:
Allow only users with a verified email to read data
Allow only Firebase authenticated users with a verified email to read documents under the collection named documents:
Restrict read/write access to user data
Allow a user to read or write only to the document that contains their user data.
In this case, we do this by setting the document ID to the user authentication ID:
Restrict read/write access to user data, take 2
Allow a user to read or write only to the document that contains their user data.
In this case, we do this by storing the user authentication ID in a field inside the document. The name we gave this variable is userID.
Check variable type
Allow a field to be written only if it is a certain variable type. In this case we ensure the variable score is a number.
Prevent invalid field modifications
Allow a number variable named claps to be updated only if the new value is greater than the one stored inside the database.
Ensure values are in range
Allow a rating of 1 through 5 stars to be written for a document under the variable name rating only if the rating is a whole number, and a rating does not already exist in the document.
Allow a client to switch between different modes in their account. We don’t want the client to create a new mode. So in this case we can choose between two account modes, normal and advanced.
Allow a client to only write to certain fields in a map.
In this case, we have a map named pants where we have three different colors: black, blue, and pink. We want the client to be able to update the number of pants in inventory, but not create new pants colors.
Ensure documents are complete
Allow a client to write to a map only if the request has all the necessary fields.
In this case, we have a map named name where we have three fields: first_name, middle_name, and last_name. We want the client to be able to create a document only if it has the first name and last name set. The middle name is optional.
Allow write to string field named name only if the new string contains only letters.
In this case, we use regular expressions (RegEx) to accomplish this.
Implement expiration
Allow writing to a document only if the document has not yet expired.
In this case, the expiration date is in the form of milliseconds since epoch, and is stored in a field named expiration. We use the time in milliseconds that the write request was sent to validate the action.
Conclusion
The rules above cover a broad field of security, and each case is just a simple way to implement them. To have a secure database, you want to use them in conjunction and improve on the rules listed here. Think of these rules as a starting point, not the finish line. I hope this list of rules is able to guide you and inspire you to write your own custom rules.
Feel free to respond with some nifty security rules that you come up with.
You can also check out these links that helped me come out with these rules:
