I have plans to serve the Firebase Emulator inside a proper docker image for the use case of integration and e2e test pipeline, remotely executed. In this scenario, what are the best practices for authentication in Firebase Emulator?
I've only found documentation where the emulator's configuration is directly bind to the actual project. Thus, not allowing to externally configure a anonymous emulation with the desired specifications.
My goal is the bare minimum authorization to have the setup running inside the container itself. And by minimum, I mean that even someone with directly access to the container will not have power to affect the production environment in any sense - neither to use any authentication state saved in the container to escalate privileges.
Related
I have an idea to make my apps to be Backend Driven and for this reason I want to query Firebase Remote Config for some values which has some condition properties when they should be applied (for example: parameter show_banner should be applied only for Country: Portugal) and I want to have the possibility to use A/B testing for such scenarios.
In other words I want my backend microservice to make requests to Firebase Remote COnfig (with A/B testing feature) on behalf of mobile applications (I can have information about the version, country, mobile id etc.. in the backend). Is there any REST APIs that can help me achieving this ?
The REST API for Remote Config only allows managing the template, so the equivalent of the operations you can perform in the Firebase console.
There is no public REST (or other server) API to get a set of remote config values for a specific device. That operation is only possible through the client-side SDKs.
Several questions have asked to run the firebase-admin package in the browser, such as
Can I break the rules and use firebase-admin on the client side? Or will trying to workaround errors be for nothing?
How to properly use Firebase Admin SDK using Node.js for a web-app?
Error importing firebase-admin
https://groups.google.com/g/firebase-talk/c/Jfq054TLEFQ?pli=1
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?
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.
I have a Node.js API (built with Express.js) hosted on Firebase Cloud Functions and an accompanying web application hosted on Firebase Hosting which is supposed to interact with the aforementioned API.
I would like to restrict calls to the API so that only the web application would be able to call the cloud functions. How can I achieve that?
What I have tried:
using the App Check or more precisely Google's reCAPTCHA v3 for web apps. I have whitelisted the domain of the web application and have activated App Check token validation server side as well. The problem with App Check, however, is that I am able to obtain the reCAPTCHA attestation token from the browser (after authenticating through the web app) and use that with requests made from anywhere. This enables bombarding the API from outside the web application and defeats the purpose of using App Check in the first place.
Something to note here, the documentation for activating App Check in Cloud Functions instructs the usage of functions.https.onCall(). However, since my API is built using Express.js, I had to use a workaround to be able to use functions.https.onRequest() as instructed here.
restricting the Cloud Function from Google Cloud console to allow only clients of the same project to call the function as instructed here. Unfortunately, my web application hosted on Firebase Hosting does not seem to belong under the same Google Cloud project. Apps hosted on Firebase Hosting do not appear in Google Cloud console. Furthermore, after adjusting the Ingress settings of the functions to "allow internal traffic only", I am receiving CORS errors when attempting to access the API through the web application. I am unable to access the API from anywhere else though, which is partly the desired outcome.
Before anyone proposes limiting the domains in CORS options from within the API, while this might serve the purpose of restricting access to the API endpoints, it still would allow calling the function rapidly and thus, potentially, racking up the bill.
I am grateful for any suggestions!
Firebaser here.
This is a great question! Doug has already made some great points above, and I'll just add to that by saying that the TTL on App Check tokens reduce the replay window that you observed in your first bullet point, and this TTL is configurable.
The default TTL for reCAPTCHA v3 is 1 day to protect against running out of quota, but you can set a shorter TTL to increase the cost for an attacker trying to set up a replay attack. But please do be mindful of the associated trade-offs as described in the documentation. You can read about the associated quotas and limits here.
Unfortunately, web applications redirected from Firebase Hosting can't hook up to the GCP internal network. App Check is actually exactly what you are looking for in this situation.
Finally, because we are continuously working on improving the App Check platform, the comments you leave here are valuable for us as we decide on what anti-abuse features we want to work on next.
I have a backend system built in AWS and I'm utilizing CloudWatch in all of the services for logging and monitoring. I really like the ability to send structured JSON logs into CloudWatch that are consistent and provide a lot of context around the log message. Querying the logs and getting to the root of an issue is simple or just exploring the health of the environment - makes CloudWatch a must have for my backend.
Now I'm working on the frontend side of things, mobile applications using Xamarin.Forms. I know AWS has Amplify but I really wanted to stick with Xamarin.Forms as that's a skill set I've already got and I'm comfortable with. Since Amplify didn't support Xamarin.Forms I've been stuck looking at other options for logging - one of them being Microsoft's AppCenter.
If I go the AppCenter route I'll end up having to build out a mapping of the AppCenter installation identifier and my users between the AWS environment and the AppCenter environment. Before I start down that path I wanted to ask a couple questions around best practice and security of an alternative approach.
I'm considering using the AWS SDK for .Net, creating an IAM Role with a Policy that allows for X-Ray and CloudWatch PUT operations on a specific log group and then assigning it to an IAM User. I can issue access keys for the user and embed them in my apps config files. This would let me send log data right into CloudWatch from the mobile apps using something like NLog.
I noticed with AppCenter I have to provide a client secret to the app, which wouldn't be any different than providing an IAM User access key to my app for pushing into CloudWatch. I'm typically a little shy about issuing access keys from AWS but as long as the Policy is tight I can't think of any negative side-effects... other than someone flooding me with log data should they pull the key out of the app data.
An alternative route I'm exploring is instead of embedding the access keys in my config files - I could request them from my API services and hold it in-memory. Only downside to that is when the user doesn't have internet connectivity logging might be a pain (will need to look at how NLog handles sinks that aren't currently available - queueing and flushing)
Is there anything else I'm not considering or is this approach a feasible solution with minimal risk?
Is it possible to set up Firebase to allow Auth/DB access into a common/shared database instance - where that instance is setup to be a centralized storage location for some 3rd party service?
For example, let's say there's an analytics service called StackOverflowAnalytics.com .. and so anyone who signs up for that service, can add tracking to their app with some secret user key. And then all the tracking for that Key is pushed to the same Firebase DB instance. And then the user can login via Firebase auth and the rules will restrict that they can only access the node for their Key.
I'm working on a 3rd party analytics client for Android - along the lines https://mint.splunk.com - where I would like to provide users a small Java/Android library they can add to their Android project, and this will help them track different data points while their app is running. The data is made accessible by saving it to the cloud from the device.
I am currently using Firebase, but it seems in order for the Firebase Auth & DB of a given Firebase instance to be accessible - the "specific app signing key" (package name/etc combo) needs to be set in the console for that Firebase instance.
It seems sharing across across unknown apps is not possible on Firebase. And that if I want to support something like that with Firebase (and not have to go to another cloud storage option), then I need to set up some proxy REST client .. like in Java or PHP .. that can serve as a centralized access point to that Firebase instance. Just wanted to check with other folks first in case this has been encountered and perhaps there are best practices already established around this particular case. Thanks
Firebase client libraries are generally not meant to be repackaged for use in other libraries. They're meant to be used at the app level.
A unique SHA-1 key is required on Android for Authentication to work with a particular app identified by package name. This requirement will definitely become a problem for you if you want this to work with arbitrary apps, since you would have to manually enter one for each app that wants to integrate.
As far as I know it's not possible to do what you want without creating a proxy, as you mentioned. I assume that firebase has some app validation that make unfeasible to share the Auth/DB.
Maybe a solution for you is to make a proxy too to access data:
"It looks like in order to access Firebase Analytics data, you export it to BigQuery. This is working for me and is automated."