Could someone please explain to me why a bad actor could not create the following disruption for potential new users to my app?
The bad actor:
Obtains a list of emails from the dark web or some other nefarious source.
Acquires my Firebase keys by inspecting my app javascript -- yes my app is minified, but it would still be possible.
inserts malicious javascript code into my app sources on their local browser. The malicious code uses the Firebase sdk and my app keys to create accounts for each email address.
While there is no possibility that the bad actor could gain access to validated accounts;
nevertheless, creating these accounts would generate unsolicited email verification requests to the owners of the emails and it would also interfere with a smooth account-creation experience for those users when they actually do want to signup.
Am I missing something here?
CodePudding user response：
firebaser here
As Dharmaraj also commented: the Firebase configuration that you include in your app is used to identity the project that the code should connect to, and is not any kind of security mechanism on its own. Read more on this in Is it safe to expose Firebase apiKey to the public?
You already in your question noted that creating a flurry of accounts doesn't put user data at risk, which is indeed also correct. Creating an account in your project does not grant the user any access to other user accounts or data in your project yet. If you use one of Firebase's backend services, you should make sure that your security rules for that service don't do this either.
The final piece of the puzzle is that Firebase has many (intentionally undocumented or under-documented) safe guards in place against abuse, such as various types of rate limits and quotas.
Oh, and I'd recommend using the local emulators for most of your testing, as that'll be faster, doesn't risk accidentally racking up charges due to a quick coding mistake, and (most relevant here) doesn't have the rate limits in place that are affecting your e2e test.