0

I am making a web app with firebase firestore, the website would allow the public to signup for an account, and all authenticated users could submit reviews to businesses, thus making requests to create documents in firestore. in context of preventing authenticated users' billing attack (spam creating documents), im thinking of having security rules to rate limit per user (like the examples here How do I implement a write rate limit in Cloud Firestore security rules?), by checking the user's last timestamp of creating document. But on top of that, Im thinking of calling cloud function to disable user and revoke their tokens once they reach the threshold and get rejected in firestore security rule, and set a low sign-up quota to prevent malicious users from spawning new accounts to attack. for context this is a low traffic website (100 users per day max)

Is this a good approach to defend against malicious users? since there isn't out-of-box way to limit per-user rate without affecting read operations, what's the existing best approach to achieve that in a custom way

Derek
  • 13
  • 3
  • This is going to be tough to answer without understanding the entire use case. But why do you think this *there isn't out-of-box way to limit per-user rate without affecting read operations*? Your attempting to limit *write* operations and writes can be fully secured with rules as well. For example, a write rule could compare the current write timestamp to a prior write timestamp and if it was less than 1 minute (1 day, one week, whatever, it's just a number), deny the write. – Jay Jun 23 '23 at 17:32
  • by comparing the write timestamp in security rules, yes it would prevent a write operation, but the comparison itself requires a read operation from security rule. so an attacker could abuse requesting a bunch of writes, getting rejected by security rules, but still managed to increase my read operations. – Derek Jun 25 '23 at 02:27
  • 1
    I would suggest there is a very low chance that's going to be an issue. You are only charged one read per dependent document so someone banging on the same document 1000 times is one read. Also, you are only billed for get() and exists() requests, and you may not need that. Lastly, Firebase enables you to set [Daily Spending Limits](https://firebase.google.com/docs/firestore/quotas) which can help prevent unexpected runaway costs. I really wouldn't spend too much time on this issue. – Jay Jun 25 '23 at 13:44

0 Answers0