This is a web page located on Firebase Hosting, served dynamically through a rewrite to a Cloud Function
When browsing to the url, I receive "Error: Forbidden
Your client does not have permission to get URL [/theURL] from this server.
Everything works as long as I have "allUsers" added as a Cloud Functions Invoker on the function via the GCP console. I have confirmed this with testing just throwing that one switch and getting two different results.
I am logged into my Chrome browser with the same Google account as the owner of the GCP project
I am logged in to my Firebase website (Firebase Authentication and Firestore roles management) using the same Google account, with a Firebase __session cookie and all.
This started when I upgraded my Node.js engine from 8 to 10 with the recent warnings from Google that they're dropping support for 8. (I am assuming, but have no real idea, that the version 8 runtime environment didn't have this feature?)
I wrote these Cloud Functions without any knowledge of GCP authentication, so I am relatively confident that my coding inside the Cloud Function is secure, but if there is another layer of security that I could/should be using, I'm all for it.
I will want this website to be publicly accessible, but I can granulate the functions to public vs. non-public if necessary. (Basically, I was writing them as all publicly accessible and internally authenticated/secured anyway.)
I'm not very knowledgeable at all about the GCP authentication requirements, so it's hard for me to pin this down to one central question, but here are some questions I know I don't know:
Should Firebase Hosting be added as a member to GCP's authentication groups, so that GCP only allows service of a Cloud Function to the rewrite requests? It seems that would be the most secure and straightforward method.
Why is GCP telling my I'm forbidden when I'm the owner of the whole doggone project? Does this have to do with Firebase Rewrite or maybe HTTP requests being anonymous? If so, then how does one authenticate for a Cloud Function anyway?
Sorry for the large scope of the question; any guidance in the right direction is much appreciated.
GCP allUsers is not related to Firebase Authentication. They deal with different sets of users. A function should have GCP allUsers invoker permission in order to allow access from web and mobile apps where users are signed in with Firebase Auth. GCP does not check the Firebase user - that is up to the function to do, if it wants, using the Firebase Admin SDK.
Related
I have an issue related to Firestore, Hosting, and Cloud functions. I deployed a Nextjs application using the just-released experimental web framework support. I'm using Nextjs's Image API, and as expected, the Firebase CLI creates a cloud function for the project. Everything works fine at the start, but when I try to open a page in the application that reads some data from Firestore, it redirects to an auth page, which is unexpected.
Even when I auth with my Google account (since that's the logged-in user to the application), it returns a forbidden error and logs me out.
When I go back and try again, it returns a different error (most likely because I was logged out automatically).
I tried doing some research, and some people suggested adding an allUsers principal permission to Cloud functions, but that didn't work (Error: Principals of type allUsers and allAuthenticatedUsers cannot be added to this resource), and that's even insecure permission. Only authenticated users should be able to read data from the page as already configured in my Firestore security rules. So it's unclear what I need to do since Firebase created the Cloud function automatically or if this is related to my security rules and cloud functions.
What could be wrong? Everything works fine in my existing deployment setup to Netlify (where Edge functions are created automatically using their Nextjs plugin). I'm only trying to test the new Firebase web framework hosting features. Please let me know if you'd need me to provide some more context or debug files to better help you help me.
Thank you!
The message “ App requesting permission to access your google account “ pops up if the function runs in any region other than us-central1.
Currently, Firebase Hosting does not support Cloud Functions in any other regions, Except us-central1.
You can refer to this StackOverflow thread.
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 flutter-fire user since last fall
Note: The server client libraries bypass all Cloud Firestore Security
Rules and instead authenticate through Google Application Default
Credentials. If you are using the server client libraries or the REST
or RPC APIs, make sure to set up Identity and Access Management (IAM)
for Cloud Firestore.
Comment above is from link by firebase team. It sounds like 'server client libraries' or apis in the comment mean the requests from outside of my mobile apps, and they gon bypassing cloud firestore security rules. But when i tried the same get request with Postman with just same request from the one in my app without permission, the response in Postman console was fine, which means that there came a permission denied error.
So, here comes my question. I hope to know what types of requests exactly are equivalent to these 'server client libraries' or 'the REST or RPC APIs' mentioned in the official reference that bypass all the security rules. Postman is exactly 'the REST', and firebase worked as i wanted(produced permission denial) perfectly in this case. So there must be some specific types that firebase team actually intended to refer to be careful of.
I understand that firebase-admin sdk is one of the possible server side libraries, but exactly the same permission or auth procedures should be required when we tried to access firebase admin sdk which can control firebase data above the security rules just like firebase team commented. So the question is focusing on possible attackers' solutions to maliciously manipulate our firebase without the proper security procedures.
Hope some firebase gurus would give cool answers for the question with awesome knowledge and experiences! Thank you in advance [:
As their name indicate, the server client libraries are to be used from a server or from a "trusted environment" like Cloud Functions.
When interacting from your server (or your trusted environment) with the Firebase server APIs you don't authenticate as you would authenticate from a client application. Instead of using user accounts created through the Firebase Authentication service (e.g. email/password account) your server should use Google service accounts. More details here in the Firebase doc.
Note that for Cloud Functions, you initialize the Admin SDK with no parameters. In this case, the SDK uses Google Application Default Credentials (exactly as indicated in the documentation excerpt you mentioned in your question).
So, when your server (or your Cloud Function) interacts with the Firebase server APIs, since it is authenticated with a service account, the requests bypass all Cloud Firestore Security Rules. In other words, if you want to implement some check to allow/forbid specific operations based on specific parameters/values, you have to implement them in your code.
For the REST API, it is the same. The REST API can be used from a client application (a web app, a Flutter app, ...) or from a server.
Depending if it is a client or a server, you should authenticate by using a Firebase Authentication ID token or a service account (together with Google Identity OAuth 2.0 token), as explained in detail in the documentation.
So, when you make a request to the API with Postman without permission, as you did, the API detects that there is no Google Identity OAuth 2.0 token or Firebase Authentication ID token associated with the request and then the Security Rules are enforced => you get a "permission denied error".
In conclusion, if you correctly define your Security Rules you should not encounter any problem with "attackers maliciously manipulating" your database.
Note however that Security Rules only based on auth != null may not be sufficient to protect your data, as explained in this answer.
This question already has an answer here:
Firebase functions: Securing firebase https functions
(1 answer)
Closed 2 years ago.
I am building a Flutter Android app where an user can sign in with a customToken. I have a (Google) Cloud Function that I use to generate a customToken which is sent back to the client (Android App) to sign into Firebase. (the auth provider is not supported by Firebase as of yet - not to my knowledge anyway)
For security and cost-savings purposes, I want to only allow the Cloud Function to be accessed by authorised users, and hence, I removed the allUsers member as a Function Invoker role.
I then created a service account (within the same Firebase project) and gave it the Function Invoker role. The problem now is how do I "authenticate" the client (Android App) to access this function, without being signed in (since you need the customToken to sign in), and also without saving credentials on the client?
Or am I approaching this problem the wrong way? Should that Cloud Function be public? My knowledge of Firebase, Cloud Function and security is also very limited, so any advice/suggestion would be greatly appreciated.
Cloud IAM user permissions (such as allUsers and service accounts) don't have anything to do with Firebase Auth users.
Cloud Functions that need to be directly accessible by web and mobile clients must have IAM allUsers permission. They don't need a service account for permission.
If you need to check the Firebase Auth user account that's invoking the function, the client will need to pass an ID token to the function, and the function will need to verify that token with the Firebase Admin SDK in order to find out who the user is, then decide if the should be able to continue execution. This process is described in more detail in the documentation.
If you aren't using Firebase auth, there's not much else you can do from a security perspective, as you would have to include the credentials in the app itself, or otherwise make those credentials publicly available, which is not secure at all. Or in other words, you can't limit access to your function from just your own app code.
I have implemented Firebase Authentication in my app, using the Google Provider and the "https://www.googleapis.com/auth/drive.appdata" scope so my app can access its application folder within Google Drive
This part works fine and I retrieve the FireBaseUser once the authentication completes
What I now want to do is to access my app storage on Google Drive, but I don't know how to do this using the result of the current authentication
I tried to follow this: https://github.com/gsuitedevs/java-samples/blob/master/drive/quickstart/src/main/java/DriveQuickstart.java
But this doesn't work on Android.
The main issue is how to create the Credentials object
Do you have any idea on how to initialize a Drive.Builder instance so I can write/read to the app Google Drive folder?
Thanks
This cannot be done directly, because the Firebase & Google login are not the same, even when having logged in to Firebase with a Google account. On Android one meanwhile only has the "last logged in Google account" available for the user's Drive (the one on the device, which has nothing to do with Firebase Authentication, where Google may only be used as an "Authentication Provider").
So there are generally two options available to you:
Grant a GCP service-account access to Drive API and use Cloud Functions to access it.
Instead use Cloud Storage, which is within the Firebase eco-system and is similar to Drive.
I could also think of a combined solution approach, where users would use Cloud Storage (together with Firebase Authentication) and having a Cloud Function which uses a service-account, which eg. copies or moves uploaded files into a folder your Drive.
Concerning that (obviously server-side) Java example, the credentials.json clearly hints for a service account... and this is exactly where you can obtain this file from. However, for Android this is pretty useless - because it has major security implications, to package service-account credentials in an easy to de-compile package and distribute it on the WWW (to everybody). The Google Play Store likely would not permit you to publish or even upload that, because there are security checks in place. You could in best case only deploy that code as App Engine module, but not as an Android module.
Sorry for having destroyed your delusions and for not being able to provide a ready-made solution for 500 imaginary internet points, which pay nothing - but at least I can tell what is technically possible and what isn't - which effectively might save you lots of time, trying to accomplish the impossible.