"Trusted" and "Privileged" server environments are frequently mentioned in the docs for Firebase, but there's no formal definition. What are they?
How do I make my server trusted or privileged?
While what "priveleged" or "trusted" server environments are is not explicitly searchable (prior to the creation of this Q&A), it can be inferred from the following excepts.
In the docs for FCM setup, is the following excerpt:
The server side of Firebase Cloud Messaging consists of two components:
The FCM backend provided by Google.
Your app server or other trusted server environment where your server logic runs, such as Cloud Functions for Firebase or other cloud environments managed by Google.
Your app server or trusted server environment sends message requests to the FCM backend, which then routes messages to client apps running on users' devices.
And in the docs for general setup:
Firebase projects support Google service accounts, which you can use to call Firebase server APIs from your app server or trusted environment. If you're developing code locally or deploying your application on-premises, you can use credentials obtained via this service account to authorize server requests.
Important to notice is that both explicitly say "app server or trusted environment" which implies the two are different things.
Further, the first excerpt (though somewhat semantically ambiguous)
that examples of trusted environments are "Cloud Functions for Firebase or other cloud environments managed by Google."
Finally,
in the second excerpt is the information "If you're developing code locally or deploying your application on-premises, you can use credentials obtained via this service account to authorize server requests"
From all of this it can be inferred that:
Trusted and Priveleged Environments are generally things internal to google and therefore intrinsically trustworthy
App servers are generally anything which has access to the right credentials
And finally, you do not need to take any steps beyond having the correct credentials to make your server a "Trusted Environment." It does not need to be a "Trusted Environment," because what that term really means is "Owned by Google."
A trusted environment is an environment where you control what code runs on it. In the context of apps built using Firebase, this sets them apart from the devices your regular app runs on as malicious users can take your app configuration data and run their own code with that.
I often explain trusted environment, as:
Your development machine, since you're usually the only one working on that.
A server (or VM, container, etc) that you control. Only you (and people you trust) should have access to the server, so shared servers are not a good fit.
Cloud Functions, since only collaborators on your Firebase project can deploy code there.
Related
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 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
I have a simple web site hosted in Firebase and it is making AJAX calls to REST API endpoints in GCP Cloud Run.
I would like to limit these endpoints only to the calls coming from this site hosted in Firebase. Any call coming from any other origin should not be able to use the endpoints. What is the best way to do this?
When I was not using GCP Cloud Run, I was doing a host check on the API side to make sure that request is coming from my client but now with Cloud Run this is not possible. What else could be done?
Please note that the web-site hosted in Firebase is very simple and do not do any user authentication.
Challenge: Restrict access to a Cloud Run service to a single web application, without relying on:
Restricting access to the web application
Imposing authentication on users
This difficulty is not specific to Cloud Run. It's a general challenge for static sites backed by APIs, and a reason why many sites have authentication. As mentioned in the question comments, a server-side "host" check is not a meaningful security layer, as everything in the HTTP request can be faked. I strongly recommend you not worry about keeping your API private or add user authentication to keep the system simple and access accountable.
If that's not possible, you can still take the authentication approach by creating a single user, embedding the credentials in the site, and rotating them regularly (by redeploy to Firebase Hosting) to prevent credential theft from having indefinite access to your API. Having Firebase Auth in the middle is better than a simple API key because it prevents replay attacks from accessing your API.
I am considering to migrate an application to Cloud Foundry since I'm tired of managing my server on my own. In my current application I use Spring Security and sessions to handle my user logins. I am however clueless on how to change my code so Cloud Foundry's multiple instances support my user logged in in a somehow stateless way (but using a token). I have looked into UAA, but it seems that this is for cloud foundry users, not users of my application.
Something OAUTH2-like seems to be a solution, but it seems I would have to rely on third parties if I want to do it in a developer-friendly way. The Cloud Foundry (or Pivotal Web Services in this case) documentation is also quite unclear on the matter.
When looking at the Spring Cloud documentation, I do find information on how to use OAUTH2 providers like Github to do things like Authentication, but it doesn't show how to actually use the Principal or how to handle stuff like Authorization (role-based).
I assume there are ways to run my own OAUTH2 service, and that would be the recommended solution, but again, there's quite a lack of documentation.
Can anyone give me some pointers?
A couple of key questions here are where is your user store currently? And what do you want to do with it moving forwards?
If you manage your own users and wish to continue doing so then, after migrating your users to the appropriate backing service and updating your app to be able to bind to that service using CFs VCAP_SERVICES env variable (also see spring cloud), our session affinity should allow you to push your app pretty much as-is. Otherwise a little further discussion is required.
Does this help:
https://docs.cloudfoundry.org/devguide/deploy-apps/prepare-to-deploy.html#sessions
Cloud Foundry supports session affinity or sticky sessions for incoming HTTP requests to applications if a jsessionid cookie is used. If multiple instances of an application are running on Cloud Foundry, all requests from a given client will be routed to the same application instance. This allows application containers and frameworks to store session data specific to each user session.
I'm not sure if this was answered somewhere in the documentation, but looking at the pricing tells me that Firebase has to work with client connected to the Internet at all times.
I am currently developing an application with Java-backed server and with client side done in GWT (Javascript). The application is meant to be deployed for "corporate" clients - that means in intranets.
Will Firebase be operational in these circumstances?
Well, I guess I should have read into FAQ more thoroughly:
Can I run Firebase on my own servers?
Firebase is a hosted cloud service, so the general answer is “no.” Some customers have very specific needs for where their sensitive data is physically stored and managed, so we may make exceptions. Contact us for more info.