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.
Related
I have created an API with Firebase using Cloud Functions. GET and POST endpoints are deploeyd.
A client application is registered on the project and can access it callable functions.
I would like other client applications (using their own separate Firebase project) being able to access the API too.
However, I am concerned regarding security.
If I create HTTPS endpoints for those applications, anyone having the URL will be able to use the API ?
And if I manage to restrict access only to those authorized apps, can I allow/restrict only specific endpoints (only GET endpoints, for example)?
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'm working on a web app running on firebase services. I've created an express back-end running on Firebase Cloud Functions and hosted on Firebase Hosting. I am trying to add authentication so only users with permissions can access admin pages.
I tried implementing session cookies as described here. It was successful but unfortunately was vulnerable to CSRF attacks since Cloud Functions strips all cookies without the name __session from incoming requests so the proposed csrfToken cookie solution is impossible.
I then considered using Auth's persistence in the client's local storage and sending the token in the header of a GET request. Unfortunately, I have only found tutorials on how to do this for requests within scripts e.g. for APIs, not for GET requests directly from the browser to serve a page.
It seems that there should be a simple solution. Am I missing something? Is cloud functions not meant for serving web apps like this? Is there another way to protect against CSRF without cookies? If Cloud Functions still allows the __session cookie is it meant to be used for storing the user's Auth Token and if so does it protect against CSRF anyway?
Thanks
In the firebase Cloud Function you can implement your own Auth. However Firebase provided its own Authentication method. In the Cloud Function, it is simple use the ‘functions.auth.user().onCreate() ‘ method. You can refer to Extend Firebase Authentication with Cloud Functions documentation for samples.
As for your GET question, are you asking about how to programmatically extract the parameter from the URL? It'ss similar to this; you can pull the URL and substring the part that contain the token.
I know that we can use a Firebase backend function to send an HTTP request to Google Apps Script and receive it using "doGet()".
However, is it possible to call a Google Apps Script function from Firebase without sending an HTTP request (since it's part of the same Google account)?
My concern is with security, where one may be able to guess/sniff the right URL/parameters and then execute the Google Apps Script function (which makes a purchase). Alternatively, there may be a proper way to secure GAS web apps.
There are quite some details missing. But I think you're asking of a Google Cloud Functions/Cloud Functions for Firebase can call into an Apps Script web app or a Apps Script REST API. The answer is that they indeed can invoke those URLs (if they're publicly accessible and fall within your quota).
But that is no more security risk than that any browser can invoke these URLs. The security should not come from knowing or being able to call the URLs. If you want to secure an API, you should implement proper security on it. For more on see Authorization for Google Services in Apps SCript
We are looking into authentication/authorization for a mobile reporting app which consumes hourly/weekly/monthly commercially sensitive data over the wire using an internally provided RESTful web api service running within the MS Azure Cloud.
Stormpath's offering looks interesting in that it would appear to provide some heavy lift for the whole identity management side of things, registering users, authenticating them and producing JWT tokens etc.
Otherwise, we would have to write our own auth/user db tables and have some management overhead with that.
What I am not fully clear on is where our current unsecure, unauthenticated prototype API served up by Azure would need to intersect with Stormpath.
Can anyone, especially those familiar with Stormath elaborate on this?
I get that all the user registration, password recovery use cases would go via Stormpath and I am guessing that JWT token creation for a user would require our existing service to talk to Stormpath. Would the validation of tokens within the HTTP(S) headers of our RESTful calls be done by our Azure service locally (via some code plugin) and if so is that validation done locally or does each RESTful call have a side effect of proxying calls to Stormpath API to validate the goodness of a token?
I guess I am sensitive to performance issues regarding the whole token validation step within the Web API pipeline.
I've read elsewhere that Microsoft themselves have an offering, namely Azure AD B2C which it seems is not production ready for regions outside of US/North America as of yet.
Is that something else we should consider as an alternative to an outsourced offering like Stormpath?
One thing which looks attractive about something like Stormpath is the possibility of two factor authentication.
Without having gone into too much analysis yet, a typical use case scenario would be that sign up or password recovery would mandate that an SMS was sent to the user's preregistered smartphone number to provide a stronger validation that they (and their pre-registered device) are the intended user of the mobile app which uses the RESTful service to consume and visualise commercially sensitive data.
I work at Stormpath on our .NET libraries.
What I am not fully clear on is where our current unsecure, unauthenticated prototype API served up by Azure would need to intersect with Stormpath.
Stormpath acts as your API's source of access tokens. When someone using your mobile app needs to log in, your backend API uses Stormpath to generate an access token, or the mobile app talks directly to Stormpath to get an access token. Either way, the token allows the mobile app to make authenticated requests to your API.
Would the validation of tokens within the HTTP(S) headers of our RESTful calls be done by our Azure service locally (via some code plugin) and if so is that validation done locally or does each RESTful call have a side effect of proxying calls to Stormpath API to validate the goodness of a token?
The access token (JWT) integrity can be validated locally using middleware like UseJwtBearerAuthentication in ASP.NET. For more security, you can send the token up to Stormpath to be verified even further (for revocation and other cases), but the tradeoff is a network request. Local (fast) validation is the default, but we give you both options.
I've read elsewhere that Microsoft themselves have an offering, namely Azure AD B2C which it seems is not production ready for regions outside of US/North America as of yet. Is that something else we should consider as an alternative to an outsourced offering like Stormpath?
Using either Stormpath or Azure AD B2C is "outsourcing" your identity and user management. The benefit is that you don't have to write it yourself, and you can focus on writing your business and app logic instead. The features are similar, although Stormpath is a little more flexible on the mobile side of things (since you aren't forced to use a browser/page-based flow).