The Firebase Web-App guide states I should put the given apiKey in my Html to initialize Firebase:
// TODO: Replace with your project's customized code snippet
<script src="https://www.gstatic.com/firebasejs/3.0.2/firebase.js"></script>
<script>
// Initialize Firebase
var config = {
apiKey: '<your-api-key>',
authDomain: '<your-auth-domain>',
databaseURL: '<your-database-url>',
storageBucket: '<your-storage-bucket>'
};
firebase.initializeApp(config);
</script>
By doing so, the apiKey is exposed to every visitor.
What is the purpose of that key and is it really meant to be public?
The apiKey in this configuration snippet just identifies your Firebase project on the Google servers. It is not a security risk for someone to know it. In fact, it is necessary for them to know it, in order for them to interact with your Firebase project. This same configuration data is also included in every iOS and Android app that uses Firebase as its backend.
In that sense it is very similar to the database URL that identifies the back-end database associated with your project in the same snippet: https://<app-id>.firebaseio.com. See this question on why this is not a security risk: How to restrict Firebase data modification?, including the use of Firebase's server side security rules to ensure only authorized users can access the backend services.
If you want to learn how to secure all data access to your Firebase backend services is authorized, read up on the documentation on Firebase security rules. These rules control access to file storage and database access, and are enforced on the Firebase servers. So no matter if it's your code, or somebody else's code that uses you configuration data, it can only do what the security rules allow it to do.
For another explanation of what Firebase uses these values for, and for which of them you can set quotas, see the Firebase documentation on using and managing API keys.
If you'd like to reduce the risk of committing this configuration data to version control, consider using the SDK auto-configuration of Firebase Hosting. While the keys will still end up in the browser in the same format, they won't be hard-coded into your code anymore with that.
Update (May 2021): Thanks to the new feature called Firebase App Check, it is now actually possible to limit access to the backend services in your Firebase project to only those coming from iOS, Android and Web apps that are registered in that specific project.
You'll typically want to combine this with the user authentication based security described above, so that you have another shield against abusive users that do use your app.
By combining App Check with security rules you have both broad protection against abuse, and fine gained control over what data each user can access, while still allowing direct access to the database from your client-side application code.
Building on the answers of prufrofro and Frank van Puffelen here, I put together this setup that doesn't prevent scraping, but can make it slightly harder to use your API key.
Warning: To get your data, even with this method, one can for example simply open the JS console in Chrome and type:
firebase.database().ref("/get/all/the/data").once("value", function (data) {
console.log(data.val());
});
Only the database security rules can protect your data.
Nevertheless, I restricted my production API key use to my domain name like this:
https://console.developers.google.com/apis
Select your Firebase project
Credentials
Under API keys, pick your Browser key. It should look like this: "Browser key (auto created by Google Service)"
In "Accept requests from these
HTTP referrers (web sites)", add the URL of your app (exemple: projectname.firebaseapp.com/* )
Now the app will only work on this specific domain name. So I created another API Key that will be private for localhost developement.
Click Create credentials > API Key
By default, as mentioned by Emmanuel Campos, Firebase only whitelists localhost and your Firebase hosting domain.
In order to make sure I don't publish the wrong API key by mistake, I use one of the following methods to automatically use the more restricted one in production.
Setup for Create-React-App
In /env.development:
REACT_APP_API_KEY=###dev-key###
In /env.production:
REACT_APP_API_KEY=###public-key###
In /src/index.js
const firebaseConfig = {
apiKey: process.env.REACT_APP_API_KEY,
// ...
};
I am not convinced to expose security/config keys to client. I would not call it secure, not because some one can steal all private information from first day, because someone can make excessive request, and drain your quota and make you owe to Google a lot of money.
You need to think about many concepts from restricting people not to access where they are not supposed to be, DOS attacks etc.
I would more prefer the client first will hit to your web server, there you put what ever first hand firewall, captcha , cloudflare, custom security in between the client and server, or between server and firebase and you are good to go. At least you can first stop suspect activity before it reaches to firebase. You will have much more flexibility.
I only see one good usage scenario for using client based config for internal usages. For example, you have internal domain, and you are pretty sure outsiders cannot access there, so you can setup environment like browser -> firebase type.
The API key exposure creates a vulnerability when user/password sign up is enabled. There is an open API endpoint that takes the API key and allows anyone to create a new user account. They then can use this new account to log in to your Firebase Auth protected app or use the SDK to auth with user/pass and run queries.
I've reported this to Google but they say it's working as intended.
If you can't disable user/password accounts you should do the following:
Create a cloud function to auto disable new users onCreate and create a new DB entry to manage their access.
Ex: MyUsers/{userId}/Access: 0
exports.addUser = functions.auth.user().onCreate(onAddUser);
exports.deleteUser = functions.auth.user().onDelete(onDeleteUser);
Update your rules to only allow reads for users with access > 1.
On the off chance the listener function doesn't disable the account fast enough then the read rules will prevent them from reading any data.
I believe once database rules are written accurately, it will be enough to protect your data. Moreover, there are guidelines that one can follow to structure your database accordingly. For example, making a UID node under users, and putting all under information under it. After that, you will need to implement a simple database rule as below
"rules": {
"users": {
"$uid": {
".read": "auth != null && auth.uid == $uid",
".write": "auth != null && auth.uid == $uid"
}
}
}
}
No other user will be able to read other users' data, moreover, domain policy will restrict requests coming from other domains.
One can read more about it on
Firebase Security rules
While the original question was answered (that the api key can be exposed - the protection of the data must be set from the DB rulles), I was also looking for a solution to restrict the access to specific parts of the DB.
So after reading this and some personal research about the possibilities, I came up with a slightly different approach to restrict data usage for unauthorised users:
I save my users in my DB too, under the same uid (and save the profile data in there). So i just set the db rules like this:
".read": "auth != null && root.child('/userdata/'+auth.uid+'/userRole').exists()",
".write": "auth != null && root.child('/userdata/'+auth.uid+'/userRole').exists()"
This way only a previous saved user can add new users in the DB so there is no way anyone without an account can do operations on DB.
Also adding new users is posible only if the user has a special role and edit only by admin or by that user itself (something like this):
"userdata": {
"$userId": {
".write": "$userId === auth.uid || root.child('/userdata/'+auth.uid+'/userRole').val() === 'superadmin'",
...
EXPOSURE OF API KEYS ISN'T A SECURITY RISK BUT ANYONE CAN PUT YOUR CREDENTIALS ON THEIR SITE.
Open api keys leads to attacks that can use a lot resources at firebase that will definitely cost your hard money.
You can always restrict you firebase project keys to domains / IP's.
https://console.cloud.google.com/apis/credentials/key
select your project Id and key and restrict it to Your Android/iOs/web App.
It is oky to include them, and special care is required only for Firebase ML or when using Firebase Authentication
API keys for Firebase are different from typical API keys:
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.
Although API keys for Firebase services are safe to include in code, there are a few specific cases when you should enforce limits for your API key; for example, if you're using Firebase ML or using Firebase Authentication with the email/password sign-in method. Learn more about these cases later on this page.
For more informations, check the offical docs
I am making a blog website on github pages. I got an idea to embbed comments in the end of every blog page. I understand how firebase get and gives you data.
I have tested many times with project and even using console. I am totally disagree the saying vlit is vulnerable.
Believe me there is no issue of showing your api key publically if you have followed privacy steps recommend by firebase.
Go to https://console.developers.google.com/apis
and perfrom a security steup.
You should not expose this info. in public, specially api keys.
It may lead to a privacy leak.
Before making the website public you should hide it. You can do it in 2 or more ways
Complex coding/hiding
Simply put firebase SDK codes at bottom of your website or app thus firebase automatically does all works. you don't need to put API keys anywhere
Just looking for some general advice here.
I want to build a Slack app and publish it publicly to the Slack App Directory, for anyone to use. The basics of the app are:
When you paste a link to a specific domain in a Slack message, a bot will fetch additional information about that link from a Rest API my company built.
The roadblock I'm running into is that our Rest API uses Basic Auth for authentication, and I can't figure how or where in the Slack App setup flow to ask the user to enter their API key.
Does anyone have any advice on how to ask for user input when setting up a Slack app, so that the user can enter their API Key for our REST API?
Thanks!
OK, I will assume that the API key is individual to each user.
I would suggest to ask the API key as part of the installation process for your Slack app on your website and then store the connection between Slack user ID and API key as part of the installation process. It is in fact possible to have individual installations of the same Slack app to a workspace for each user. This is called "configurations" (e.g. the Twitter app for Slack is using this feature).
This requires each user who want to use the app to go through the installation process and also all users need to have permissions to install this particular Slack app (which can be configured by admin).
I received this error when trying to authorize my app with my own account:
Your project is trying to access scopes that need to go through the verification process.
{invalid=https://www.googleapis.com/auth/contacts}
If you need to use one of these scopes, submit a verification request. Learn More
When I use a different account, the error message is different:
This app hasn’t been verified to access:
{invalid=https://www.googleapis.com/auth/contacts}
Are you the developer? If this project needs these scopes, sign in to an account with access to edit your project and try again.
If not, contact the developer for help.
As per the announcement on May 11, 2017, publicly available applications with access to certain user data must pass review. If you see an access error for your app, submit a request using our OAuth Developer Verification form.
For personal-use apps and those you are testing, join the Google group Risky Access Permissions By Unreviewed Apps, which allows you to approve data access for personal and testing accounts. See the Google API Services User Data Policy for more information.
UPDATE: Corrected broken link to form.
The main use case is using IPython as CLI to my own Google accounts. What I am really after is minmizing the fussing around between starting the IPython shell and actually issuing usefull calls against the API.
The docs for authenticating with Google APIs focus on setting up application which other user will use to access their data.
This leads to a lengthy Oauth dance involving a browser in order to allow other users to authenticate without compromising their credential.
However, I do not mind sharing my private credentials with myself. I am not planning on sharing the code. If I did share the code I would use something like dotenv to separate the credentials from the code.
Twitter provides developers a second set of credentials
that allows developers to access their own accounts for testing.
Thus it is possible to access ones own account programmatically
by just providing to sets of credentials: the developer credentials that allow the calls to the API and the other credentials that grant access to the developers own data. For example:
from twitter import *
t = Twitter(
auth=OAuth(token, token_key, con_secret, con_secret_key))
# Get your "home" timeline
t.statuses.home_timeline()
# Update your status
t.statuses.update(
status="Tweeting from Python")
Where con_secret* are the developer credentials and
and token* are the account access credentials.
How can I do something equally simple with Google APIs?
Where can I get credentials to access my own account?
How would I use them in Google API?
As an example what would be the simplest procedure for retrieving the contents from one of my own Youtube playlists?
I have com to think that a Python headless browser library could be give me what I need. I have asked a related question on SE Software Recommendations
https://softwarerecs.stackexchange.com/questions/35744/python-headless-browser-library-for-oauth2-authentication-from-ipython-console
I would like to download a set of credentials
Google offers this ability through it's client_secrets.json file. There are different ways to download this, depending on the type of account you want to use (Web application, installed application, Service account). The different techniques can be found here .
Store the credentials locally and keep using them without requiring
new credentials every call
This also isn't a problem, the client secret is valid until you renew it - AFAIK there is no automatic expiry unless you specify otherwise.
Once you have downloaded your client_secrets.json, store the file in a non-public directory (normally inside your project directory/config).
Similar to the downloading of the file, there are different techniques (flow classes) to use the JSON file depending on what type of account you are using. As an example, the below would be used for installed and web applications;
from oauth2client.client import OAuth2WebServerFlow
...
flow = OAuth2WebServerFlow(client_id='your_client_id',
client_secret='your_client_secret',
scope='scope URL here',
redirect_uri='http://example.com/auth_return')
Other flow class examples can be found here
Hope this helps - If you need further information, the official documentation (which be warned, can be incredibly inaccurate and confusing) can be found here https://developers.google.com/api-client-library/python/guide/aaa_oauth
I am considering developing an application for the Apps for Business Marketplace. I see that new rules takes affect on November 19th. Referring to the new documentation (https://developers.google.com/apps-marketplace/) I do not see that any SSO requirement exists. There is allot of talk about migrating to new sign on methods, but I see no mention of sign on requirements.
What are the sign on requirements as of November 19th?
If SSO continues to be required or if I publish before Nov. 19th, my application requires security token from my API, in order to carry out API exchanges. To get this token a user/pass exchange is required one time. They would never need to enter a user/pass for my app after that. Will a one time exchange for the security token be denied under a SSO requirement?
For example the statement regarding SSO that an app cannot do is:
The end user should not be required to enter a username and password when invoking an application from within Google Apps. (https://developers.google.com/google-apps/marketplace/sso)
In my case it would not be required for the user to enter every time, just on the initial creation of the account. After that I would retain the token from my site, encrypted with the Installed App.
Would my app be denied for requiring this one time exchange under the SSO policy?
Mark
You will have to use SSO (or should if at all possible) -- see this part of the documentation: Besides, that is a better practice and should make your users feel more trust for your application.
From what I gather (note that I'm building my first marketplace app) you should not prompt users to enter username/password on your site. I am creating user record & storing token behind the scenes. So the user sees Google authorization screen, agrees to let my app use some data, accepts and sign-in right away without any prompt to create an account. After this, user will not be prompted in the future because I have their google id linked to a user record.
From their site - https://developers.google.com/google-apps/marketplace/sso#user_experience
As long as you don't have any intermediate screen, your app should be approved.