So far I've learned that Firebase's Security Rules play an important role in keeping our data secure regardless of the platform we're using. But I found that the Web + JavaScript combo and other implementations might be purely exposed to risk if developers structure them in such a way that firebase credentials can easily be seen on the client scripts.
Thankfully, Firebase has support for REST API's in a variety of languages which can mitigate the risk, somehow. For this purpose, I took a look at Kreait's Firebase Admin SDK for PHP for a Web data administration portal that I am creating.
Here is a simple demo for the Firebase Admin SDK for PHP.
The following good points that I found for this library are:
- Firebase credentials are written on the backend scripts, they are hidden on the front-facing clients
- Queries and database operations and implementation are hidden from the clients
- Has backend support for Firebase real-time database, authentication and user management
My questions are:
- Are my firebase credentials really secure, will it not be broadcasted to the world when using this approach as opposed to just putting it in a plain javascript file?
- Are there other ways to make the firebase credentials and data more secure (aside from encrypting data, hiding them on backend scripts thru REST implementation and properly-structured security rules)?
Thank you in advance for your comments and suggestions.
There's no security risk in exposing information like the API Key or Project ID in your front-facing application (see https://firebase.google.com/docs/web/setup, it's the recommended procedure) - your web application can only do what the currently authenticated user is allowed to do.
There's, of course, the risk that the security rules are not well defined, but that's the case with a backend application as well - a stupid example: when you create a passwordless account on a server, anyone can log in with that account ^^.
Concerning the Admin SDKs: their primary purpose is to perform administrative and/or backend tasks. If you shift your business logic from the client (= Browser) to the backend, you will lose a lot of the functionality that the web libraries provide out of the box. You will have to re-implement functionality, pass data from the frontend to the backend and back... I don't think this would be worth the hassle.
So, my recommendation is: don't worry about the config snippet that is visible when looking at the JS code in the browser and test your security rules extensively, preferably with an automated test suite, and you should be just fine.