Update (May 2021): Thanks to the new feature called Firebase App Check, it is now actually possible to limit access to the backend services in your Firebase project to only those coming from iOS, Android and Web apps that are registered in that specific project. While the keys will still end up in the browser in the same format, they won't be hard-coded into your code anymore with that.

If you'd like to reduce the risk of committing this configuration data to version control, consider using the SDK auto-configuration of Firebase Hosting.

So no matter if it's your code, or somebody else's code that uses you configuration data, it can only do what the security rules allow it to do.įor another explanation of what Firebase uses these values for, and for which of them you can set quotas, see the Firebase documentation on using and managing API keys. These rules control access to file storage and database access, and are enforced on the Firebase servers. If you want to learn how to secure all data access to your Firebase backend services is authorized, read up on the documentation on Firebase security rules. In that sense it is very similar to the database URL that identifies the back-end database associated with your project in the same snippet: See this question on why this is not a security risk: How to restrict Firebase data modification?, including the use of Firebase's server side security rules to ensure only authorized users can access the backend services. This same configuration data is also included in every iOS and Android app that uses Firebase as its backend. In fact, it is necessary for them to know it, in order for them to interact with your Firebase project. It is not a security risk for someone to know it. The apiKey in this configuration snippet just identifies your Firebase project on the Google servers.

Recaptcha bypass api