Firebase - restrict API key for web application - firebase

I just got a mail from the Firebase support that my current API key restrictions for the Firebase API key lead to malfunctions for the Firebase Installation API. Since, I have a web application and not an iOS or an Android app, I´m assuming that this is not a real issue for me at the moment.
However, this got me wondering if I enabled all necessary HTTP referrers (websites) in the Google Cloud Platform to ensure a working environment for my web application. Let´s say my domain is called www.domain.com and my Firebase project is called projectx. I currently have these two entries in the HTTP referrers for the Application restrictions:
www.domain.com/*
projectx.firebaseapp.com/*
Is there anything else I should enable? Because I saw that Firebase also enables multiple domains such as projectx.web.app by default.

It's fairly simple: you need to enable the domains that your app uses.
The two domains you have are the defaults for cases where you have a common domain:
www.yourdomain.com/* is the custom domain that you typically share out with people.
projectx.firebaseapp.com is the default domain generated by Firebase, and is typically also used in sign-in screens (although you can change this).
You may also want to add:
projectx.web.app, which is a newer default domain that Firebase creates. But this is not required, so only add it if you expect to hand it out to folks.
localhost, which is handy for local testing

Related

Prevent front-end generated email sign-in links when generating and sending these via backend

I am using firebase admin sdk on the server to generate sign in links and send them out via custom SMTP api.
I just glanced at https://firebase.google.com/docs/auth/limits and I am well within these, but I believe there is nothing stopping a malicious third party from creating/requesting sign-in links via front end code. Is there a possibility to disable this functionality so it is only available to admin acc?
Additionally, I'd like some emails (i.e. multi factor enrolment) to not be possible, but again, given that someone can obtain some of my firebase front end details, they technically can send these?
You can restrict the API key from accessing an API (e.g. Identity Toolkit) but not disable a single method of the API for client.Sign up and delete user can be (that requires upgrading to Identity Platform) .
Firebase generates an API key when you add a web app. You can either update that or create a new key from API Credentials console.
You can then restrict what the API key in Firebase web config has access to:
However, Firebase Auth Client SDK will not work as Identity Toolkit is not selected. You'll have to proxy the requests through your backend and use a different key that can be used from your server's IP only.
Firebase Admin SDK will still be functional as usual so you can use that to perform other operations like updating/deleting users. You'll just have to write APIs on your backend for what could have been done using client SDK directly (or use Admin SDK when possible).
It might be a lot to update and I would not recommend unless you are facing rate limiting issues where Firebase Support should be able to help.

How to restrict Firebase Cloud Function to accept requests only from Firebase Hosting website

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.

Restrict Google Firebase access to specific HTTP referrers

I have an API key specifically for Firebase and I have it restricted like so:
However, when I connect to Firebase from a different website (on front-end side) it still works.
I've tried connecting Google Maps and it doesn't work (because of the wrong referrer) but Firebase works.
How can I restrict Firebase access to specific web domains?
Note: I'm not using Firebase Auth, I'm only using Firestore as a database.
Double check if your domain accepts HTTP and HTTPS because both require separate restrictions. Also, try adding restriction that includes a wildcard path.
Here's an example:
https://www.test-domain.com
https://www.test-domain.com/*
http://www.test-domain.com
http://www.test-domain.com/*
Reference: https://cloud.google.com/docs/authentication/api-keys#adding_http_restrictions

Firebase API Key Application Restriction Problem

I received an alarming email from Google a couple of days ago stating that:
[Action Required] Firebase services for your application are malfunctioning due to Application restrictions
I have a Vue based website that uses Firebase for Authorization of users and storing files they are uploading. When I configured the API key that I set up, I restricted this key on the application level, to only work from the address of my website.
I did not impose any API restrictions - Under API Restrictions the radio button with Don't Restrict Key is marked
Having said that, when I try to use my website, I get the following error:
[403] Requests from referer [WEBSITE] are blocked.
The email I got from Google stated that:
Firebase SDK updates on February 27, 2020 (Android) and January 14, 2020 (iOS) replaced the Firebase Instance ID service with a dependency on the Firebase Installations API.
As a result, Firebase services like Firebase Cloud Messaging will malfunction for users who installed your app after it was released with updated Firebase SDKs. Additionally, repeated failing requests to Firebase may slow down the end-user experience of your app.
Application restrictions you have applied to the API key used by your Firebase application need to be updated to allow your application to use the API key.
Inside this mail, there were the following instructions:
Open the Google Cloud Platform Console.
Choose the project you use for your application(s). Open APIs &
Services and select Credentials.
Click Edit API key for the API key in question.
Scroll down to the Application restrictions section.
Change the radio button to None, and click Save, or add your
application to the list of allowed Android apps, iOS apps, or HTTP
referrers, respectively.
If the radio button already shows None you may be looking at the
wrong API key.
You can check which API key is used for the Firebase Installations
API by looking at the service usage page for your project.
Since I do not have any API restrictions and there is also no other API key that I have, I don't understand how to solve this situation.
One option that works is having no application restrictions, but I don't think that is the correct solution.
I also tried changing the API Restrictions to allow only the services from Firebase that I am using, but that did not fix the problem.
Any help or direction to a solution, will be appreciated.

Can Firebase Database be set up to host data for 3rd party client? (e.g., analytics service)

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."

Resources