1

I would like to avoid exposing private credentials in client apps. Doug Stevenson said firebase-authentication-vs-firebase-admin :

The reason why you can't use the Firebase Admin SDK in your app is because you would have to ship private credentials with your app in order for the SDK to operate By saying Admin SDK did he mean when we use for example:

import * as admin from "firebase-admin";

And what about :

import firebase from "firebase/app";
firebase.database().ref ... ?

Is this snippet considered as admin SDK ? To configure firebase we would still need to ship private credential with our client app, which is a security hole. So should we consider NEVER use firebase.database() or firebase.firestore() in client apps and instead use a cloud function ?

jsIsAwful
  • 63
  • 4
jean goffin
  • 13
  • 3
  • Please include a link to where you copied the quote from, as context is often really important to understanding such statements. – Frank van Puffelen Aug 17 '20 at 16:35
  • Thank you Frank. I completely understand now. The only remark I would like to say is that when you develop a mobile application, sometimes you have business rules. For example adding one to upvote and then saving this number to firebase through Javascript SDK. This is not secured because one could change this logic and add 100. So you would need to hide business rule + persistance behind a cloud function and use what you explained in the following question : [https://stackoverflow.com/questions/48575730/how-to-protect-firebase-cloud-function-http-endpoint-using-authenticated-id-toke]. – jean goffin Aug 19 '20 at 08:32
  • A lot of business logic **can** be encoded in security rules, including many voting scenarios. See my recent answer about that here: https://stackoverflow.com/questions/63441847/in-firebase-realtime-database-rules-how-do-you-give-write-access-to-the-users-w/63459749#63459749 Whether you want to write such security rules or write the same logic is up to each developer of course. Both are valid approaches. – Frank van Puffelen Aug 19 '20 at 14:21

1 Answers1

0

If you ship your administrative credentials with your application, anyone can grab those credentials and start calling any API on your project in whatever way they see fit. You have no control whatsoever over this usage, as they'll have the administrative credentials.

For this reason you should indeed not use the Admin SDK in the app, but instead wrap the functionality you need in a custom API (such as in a Cloud Function), where you can ensure its usage is authorized.

This is different from the second snippet in your question, which uses the regular JavaScript SDKs from Firebase. These SDKs don't use administrative credentials to access the project, but instead use the configuration data that is explained here: Is it safe to expose Firebase apiKey to the public?

Access through this configuration data is guarded by the server-side security rules that you've configured for your project. So while the user can still copy the configuration data and call the API on their own, any access has to go through the security rules you configured. And in those security rules you then ensure they can only access data they're authorized to.

But since the Admin SDKs bypass the security rules by design, you won't have that option when you ship the administrative credentials in your app.

Frank van Puffelen
  • 565,676
  • 79
  • 828
  • 807