Since Firebase Firestore is priced per operation (read, write, delete), my biggest concern is someone may get their hands on a valid endpoint, to either read, write, or delete a document, and just perform this operation numerous times outside the expected scope of its use.
Are there any measures that prevent malicious requests? Like if an operation occurred 10,000 times per minute, does the user then experience some kind of lock-out or would these requests be considered legal?
I understand there are database security rules, but they seem insufficient. Sure, I can check if a user is authenticated, etc, but what is to stop a malicious user from getting authenticated, figuring out where the valid and permitted endpoints to read, write, or delete documents, and just creating a script to do that on repeat?
I also understand that I can set daily spending limits. But that would just limit the amount of money I was spending, not a malicious user who could potentially use up those limits and cause the database to stop working.
EDIT: My question is not concerned solely with billing. It is concerned with malicious users who MAY HAVE access to read/write a document AND abuse this right by writing a script that drives up the number of operations with the intent of abuse. Does Firebase have any measures to stop this or not?
And if the response is "There exists security rules" then please tell me how these security rules can be written to not allow more than 100 requests per minute from the same user or something along those lines.
Security & Protection While Firebase does have a CDN, it doesn't offer you distributed denial of service attacks (DDoS) prevention, web application firewall (WAF), or rate-limiting. All of these are incredibly important to prevent malicious actors from breaking your system or stealing your data.
Firestore offers robust access management and authentication through two different methods, depending on the client libraries you use. For mobile and web client libraries, use Firebase Authentication and Firestore Security Rules to handle serverless authentication, authorization, and data validation.
How it helps: Firebase Authentication uses the data to enable end-user authentication, and facilitate end-user account management. It also uses user-agent strings and IP addresses to provide added security and prevent abuse during sign-up and authentication.
Have in mind that Firestore rules do not apply to the Firebase Admin SDK, commonly used in Cloud Functions and other trusted environments. 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.
To keep personal data safe, Firebase employs extensive security measures to minimize access: Firebase restricts access to a select employees who have a business purpose to access personal data.
Monitor your usage. To monitor your Cloud Firestore usage, open the Cloud Firestore Usage tab in the Firebase Console. Use the dashboard to gauge your usage over different time periods. Note: As a result of how the dashboard computes usage, the numbers reported can differ slightly from billing reports.
Firebase uses API keys only to identify your app's Firebase project to Firebase services, and not to control access to database or Cloud Storage data, which is done using Firebase Security Rules. For this reason, you do not need to treat API keys for Firebase services as secrets, and you can safely embed them in client code.
First, I feel the need to clarify that I love Firebase. But... this is probably one of the most annoying aspects of it. I feel this should come solved out of the box in the form of a configurable threshold per user.
With that said. IMHO you have only 2 viable options:
This is the easy answer and it defeats the main advantages of Firestore. So I wont dig deep here. Just know that it would be a valid option to create a cloud function endpoint and validate or block requests based on your backend logic.
The only way (that I could discover) to solve malicious user behavior is to keep a counter of operations by user.
This will obviously incur in extra costs for the cloud function, the extra writes to keep the counters and the extra reads used to get the private document with the counter in the security rules validation.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With