This question already has answers here:
Is it safe to expose Firebase apiKey to the public?
(10 answers)
Closed 2 years ago.
I'm trying to call the Firebase API. To call this API, we need to specify a user config key. How can I hide this key in my code? I have no idea how to do.
If I use the environment.ts file, after build, those keys are exposing in the main.js file.
main.js
Keys Exposed
Is there any way to avoid the exposure of these keys in main.js file?
Firebase is designed such a way that you do not have to hide these keys.
Please refer to doc here and extract below:
Unlike how API keys are typically used, API keys for Firebase services are not used to control access to backend resources; that can only be done with Firebase Security Rules. Usually, you need to fastidiously guard API keys (for example, by using a vault service or setting the keys as environment variables); however, API keys for Firebase services are ok to include in code or checked-in config files.
Related
Using Google Firebase Functions as a backend of the small application.
Functions are accessing to the Firestore and Realtime database, therefore they need service account credentials file.
On the other hand, I'm trying to automate the deployment of the functions using Github Actions.
Currently I places the credentials file inside the repository. I know that it's not secure.
What is the proper way of storing service account credentials file in this case?
Firebase projects, are, in effect, Google Cloud Platform projects.
More specifically, when you create a Firebase project, an associated Google Cloud Platform project is created for it.
Therefore the process for storing credentials is the same as in Cloud Platform, which is to say in a file, somewhere relatively safe.
This file should be accessible to your Function if it is required, and should either have its path specified as part of an environment variable or explicitly declared in code.
You are already storing it the proper way, because the improper way would be to insert the contents of the JSON file directly into code.
To prevent others from seeing the contents of the JSON file, simply set the respository as private.
This question already has answers here:
Is it safe to expose Firebase apiKey to the public?
(10 answers)
Closed 1 year ago.
It is very likely the case I am misunderstanding how all of this works as I am still a newer programmer, but in every course I have taken I have been told not to expose any credentials within the code.
In this Firestore documentation, it tells you to store your service account's credentials as a JSON file and include the file in the directory for the SDK to access. Am I wrong in thinking this is a security issue?
Firestore Getting Started Documentation
Under Initializing Firestore
To use the Firebase Admin SDK on your own server (or any other Node.js environment), use a service account. Go to IAM & admin > Service accounts in the Cloud Platform Console. Generate a new private key and save the JSON file. Then use the file to initialize the SDK:
const serviceAccount = require('./path/to/serviceAccountKey.json');
admin.initializeApp({
credential: admin.credential.cert(serviceAccount)
});
const db = admin.firestore();
Am I missing something here? Why is it okay to do this?
In fact it depends how we interpret "not to expose any credentials within the code."
Firstly, a main important rule, is to never include secrets (password, or service account keys, or any other confidential data) into the source code, and especially in source code configuration (git / github).
Secondly, in some situation, the only solution to authenticate to a service or API is to use a service account key. In this case, we must keep this file separated from source code, and provide it to app by an environment variable pointing to it.
If your code is running on Google Cloud Platform (App Engine, Cloud Functions, Cloud Run, Firebase Functions...), you can use default authentication provided directly by GCP, and avoid any service account key.
Check Firebase documentation.
In this case, you keep it just for development purpose on your local machine.
Firebase docs suggest firebase auto-created keys should not be restricted and unlike other sercet keys can happily appear in website's source:
Unlike how API keys are typically used, API keys for Firebase services are not used to control access to backend resources; that can only be done with Firebase Security Rules. Usually, you need to fastidiously guard API keys (for example, by using a vault service or setting the keys as environment variables); however, API keys for Firebase services are ok to include in code or checked-in config files.
The API keys auto-created by Firebase, by default, have no restrictions.
Secure your database and Cloud Storage data by using Firebase Security Rules, not by restricting and/or obscuring your API keys.
However, it seems that when we include our firebase key in our source code, it can be used by a malicious attacker to call paid Google services, such as Custom Search APIs which costs $5/5000 queries, thus draining the Google console balance of a poor unsuspecting victim.
Also, it seems adding restrictions to Firebase keys is not working - either preventing the key from working or triggering a creation of a new auto-generated key instead (see here, here, here)
So should we somehow restrict the api-key,
hide the key from the website's source
or something else?
I wasn't able to find anything about he malicious attacks using an API Key auto generated and can be restricted without any problem. Most of the posts you commented on have responses on how to solve their problems with the restriction options. Also, google documentation does recommend some API Key restriction.
Also, you have the App check to limit access to the backend services in your Firebase project.
Here there is also an article about security of the API keys in firebase.
So, after testing around and looking through some pages I think it's pretty safe to let some of them unrestricted and another ones restricted depending on what they are accessing to and you shouldn't have any problem.
This question already has answers here:
Is it safe to expose Firebase apiKey to the public?
(10 answers)
Should I hide firebase api keys into backend? Not due to data security but project cloning issue
(2 answers)
Closed 2 years ago.
I have been messing around with Firebase in a web app and realized there's something I don't understand.
In order for the JS code to send data to the Firebase servers, your apiKey has to be in the JS. But then that means your API key is public, and anyone using your website can inspect the code and just send arbitrary commands to Firebase on your behalf from the dev tools, or from any other site now that they have the API key.
I know I must be missing something, since this would make Firebase not useful. What is it I'm missing? What prevents users from sending arbitrary commands to Firebase with your ApiKey?
This question already has answers here:
Is it still possible to do server side verification of tokens in Firebase 3?
(2 answers)
Closed 6 years ago.
My Android app currently uses Google sign in and this works well. I add the tokenId to every server request and then verify it on the server. This was very easy to implement using this example (I'm using python).
I'm migrating this to go through Firebase so that I can easily add other authentication providers. My problem is that I can't seem to verify the token on the server. All I need is verification, no creation. Firebase seems to provide libraries only for Node.js and Java so I ccould use a standard JWT library like pyjwt. But where do I find Firebase's public key in order to verrify the token?
I found the answer in this post. The public keys for Firebase can be found here. The kid field in the header determines what key to use.