0

Several questions have asked to run the firebase-admin package in the browser, such as

However, both the questions and the answers given do not properly distinguish between the "browser vs. server/backend" distinction and the "end-user vs. privileged" distinction. A common theme seems to be warning against opening up firebase-admin for end-users, which is obviously a security risk, but they do not explain why a privileged user cannot access privileged Firebase functionality from code running in the browser, only from a backend / server.

So, assuming that a user has sufficient privileges (say, firebase project owner) and is willing to perform whatever authentication needed to transfer these privileges to code running in the browser -- what reasons are there for not doing this? Will it not work? Are there security risks? Is it simply discouraged because a significant fraction of developers will make mistakes WRT the exact requirements for making this work securely?

Martin Geisse
  • 1,189
  • 1
  • 9
  • 22

1 Answers1

2

I think you have a misunderstanding about what a "privileged user" is, as you say.

firebase-admin is initialized with a service account. This is not the same as an Firebase Auth user account. Service accounts are entities belonging to a cloud project that are granted privileged access to some resources in that project. This is how fireabse-admin operates - you init with a service account and gain that privileged access. firebase-admin does not init with a user account.

You never want to expose a service account credentials to a web browser. That's a huge security risk. Since firebase-admin requires a service account, you will never want to use firebase-admin in the browser where it will be seen as public information.

The whole point of the documentation on the matter is to get you to write code to send Firebase Auth user tokens to your backend, where you can safely validate them and decide if that end user should be able to perform privileged operations using firebase-admin. There is really no safe workaround to this scheme - this is the pattern you should follow.

Doug Stevenson
  • 297,357
  • 32
  • 422
  • 441
  • My understanding is that a "privileged user" has an IAM account and the privileges necessary to perform "admin" operations, such as bypassing firestore rules. However, I thought that this could by *any* IAM user with these privileges, not necesarily a service account. (I do know the difference between user accounts and service accounts, as well as IAM users and Firebase users). Can privileged "users" really not be privileged IAM users, but only service accounts? – Martin Geisse Dec 04 '21 at 16:50
  • "Since firebase-admin requires a service account, you will never want to use firebase-admin in the browser where it will be seen as public information." -- I understand that using a service account in the browser is not how things are intended to be used, but what do you mean by "seen as public information"? – Martin Geisse Dec 04 '21 at 16:51
  • You must use a service account to initialize the SDK. IAM is only used for permissions in the web console. If you were to ever expose a service account as data made available your app, it is effectively leaked to the public and can be exfiltrated by a malicious user. Don't do that. – Doug Stevenson Dec 04 '21 at 16:59
  • I think several things got mixed up. (1) Why is a regular IAM user account (e.g. my own user account that is a "project owner") with sufficient permissions not able to initialize the SDK? What specifics of a service account make the difference? AFAIK, all services I talk to through firebase-admin (e.g. Firestore) only require my account, user or service account, to have the required permissions in IAM. (2) I don't have an app but a website. If I entered service account credentials there, these credentials would live in my browser's local storage. How could they be exfiltrated by anyone else? – Martin Geisse Dec 04 '21 at 18:31
  • There are too many questions here for a Stack Overflow post, which is ideally limited to one per post. I suggest posting to firebase-talk if you want open discussion. https://groups.google.com/g/firebase-talk – Doug Stevenson Dec 04 '21 at 19:14
  • I'm not aiming at open discussion. The one question is: "Why can firebase-admin not be run in the browser?" This still hasn't been answered. The thread above is filled with side-discussions about things that were never in-scope for the question, like Firebase Auth users or hardcoding credentials in an app. The scenario is, and always was: user with sufficient privileges (hence IAM user), enters credentials in a website, and the JS of that site tries to initialize the firebase-admin package with those credentials. Works or not, and are there security implications? – Martin Geisse Dec 04 '21 at 20:22
  • "Why can firebase-admin not be run in the browser?" The Firebase team decided that the Admin SDKs can only be used in trusted environments, such as your development machine, a server you control, or Cloud Functions. This explicitly excludes browser environments. If you think you have a use-case where direct access from the browser is warranted and safe, consider calling the relevant REST API directly with an auth token that grants the necessary access. – Frank van Puffelen Dec 04 '21 at 20:49
  • Do you have any hints / links to read on why the browser is considered untrusted? After all, a typical browser has much tighter security in place than a typical Node.js process. Also, if the browser was untrusted, why would it be allowed to call a REST API that performs backend functionality? If the browser was untrusted, why would I be expected to operate the Firebase console website or the GCP console website in it? – Martin Geisse Dec 05 '21 at 05:39
  • Anything running on an end user's device is considered untrusted. Who knows what sort of malware might be running in the browser (via plugin, or simply typed-in javascript in the dev console), in another privileged process the could be monitoring the browser process, or even baked into the OS itself. We just don't know, so we don't trust it. This is the norm - never trust a machine that you don't fully control. This is why the admin SDK and service account credentials should not be allowed on end user devices. You are free to disagree with this, but you can't force Firebase to agree. – Doug Stevenson Dec 05 '21 at 18:07
  • The generalized security practice itself is called "Zero Trust Security Model". You should be able to web search to read more about it. There is a lot to read. – Doug Stevenson Dec 05 '21 at 18:10
  • I never asked about end users. The browser is running on the privileged user's machine. The same machine stores an identity token that grants access to firebase-admin for firebase-cli and gcloud CLI. If that machine was compromised by malware, it's game over anyway even without running firebase-admin in the browser. – Martin Geisse Dec 06 '21 at 06:15
  • Please note that I specifically asked this question about the difference between browser vs. Node.js, nothing else, therefore both running on the same machine, by the same (privileged) user, because all the other posts that asked this question were responded to by the same strawmen you are bringing up right now. – Martin Geisse Dec 06 '21 at 06:15
  • I think your question doesn't really capture the issue that you have at hand. I also think it's probably off topic for Stack Overflow. I suggest posting to firebase-talk and ask the Firebase staff directly why they designed it this way. If you have a feature request, you should file that with Firebase support. – Doug Stevenson Dec 06 '21 at 16:22