Replies: 1 comment 3 replies
-
This is out of scope for this repo really, I think you want to take this up with the underlying repos either firebase-android-sdk / firebase-ios-sdk / firebase-js-sdk (platforms with AppCheck) or more likely StackOverflow with appropriate firebase tags so you get the attention of the relevant google developers We wrap+expose the APIs but the upstream documentation + support channels should be considered canonical with respect to security concerns + usage. Not trying to pass the buck but I definitely don't want to speculate non-authoritatively on something with money or security concerns, I hope you understand |
Beta Was this translation helpful? Give feedback.
3 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Hi,
Although I fully understand the use of AppCheck, I still wonder how it can help against spamming request to an API endpoint.
In the scenario of a hacker using OpenBullet or whatever hacker tool to spam thousands of requests per minutes to a specific endpoint (for example, a Signup endpoints to create thousands of fake profiles in a social app):
I mean, as long as the TTL didn't expire, I guess all their requests will pass the check thus they could use their hacker tool and pretend to come from the untempered app? Or am I missing something?
I guess a solution would be to:
1- forceRefresh the appcheck token on each fetch request from the mobile app
2- expire the received appcheck token programmatically after successful verification from the backend, so that further request would need a new one that can only be generated from the app, thus making it harder for the hacker?
Beta Was this translation helpful? Give feedback.
All reactions