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
We are using Go server side code to interact with Google Ads REST API.
Namely, we authenticate it with help of "golang.org/x/oauth2" and
"golang.org/x/oauth2"packages.
In May (and recently again) we've got a email from Google regarding deprecation
Out-of-band flow, essentially rewording of this
one.
But additionally to common information, Google email listed account, which we
are using to authenticate, as being used in OOB flow and going to be blocked.
We checked our sources and available sources of mentioned packages but was not
able to find redirect URIs which are said to be used for OOB flow as one of
those:
redirect_uri=urn:ietf:wg:oauth:2.0:oob
urn:ietf:wg:oauth:2.0:oob:auto
oob
We explicitly use http://localhost in our code and long-live refresh token
(which seems never expires).
We also tried to use tcpdump to monitor our API calls, but was not able to
learn much from it, because calls are made via https and, therefore, encrypted.
We considered to use man-in-the-middle kind of proxy like
https://www.charlesproxy.com/, but haven't tried it yet, because it become
non-free and because of complexity of setup.
We tried to log our requests to API endpoint with custom RoundTripper, but
have not spotted anything suspicious. It seems that we're using refresh token
only and exchange of code to refresh token just never happen in the code.
Because of this, we don't think that further logging or monitoring with
decrypting https packages may help (but we open to suggestions how to do it better).
Finally, we decided to create a new OAuth 2 Client in the Google console with
fresh set of client id, client secret and refresh token. We obtained a new
refresh token with oauth2l and replaced
credentials in our configuration. But still, we are not sure that new account
will not be blocked by Google due OOB deprication, because seemingly it looks
the same as old one.
Questions:
Why may Google mark our account as OOB?
How can we ensure that newly created account will not be blocked?
Same here.
I find out an answer, that says "Desktop" type of Credentials uses OOB by default. Probably you need to create new Credentials with type "Web"
I'm wondering if it is somehow possible to display a private report if we don't have access to the account or company's Data Studio environment? Using the Google API would be ideal.
The reason why we need an API is because the reports need to be displayed on a distributed network of displays where user interaction is not possible. They are all separated from each other and run on their own browser instance. Setting the reports public to embed them is not an option due to sensitive data being exposed to the internet. Embedding is fine but we need some way of accessing the customers data without user interaction, i.e. via access tokens or something. If the user authenticates to our app beforehand and that allows us to then use their access token inside of the embed iframe would be fine too.
As far as I can tell I cannot display private reports through the official google-data-studio API. I did find another stackoverflow link that mentions something about community connectors. Would this still be a solution to our problem if we don't own the reports itself? We are just displaying the reports but do not have access to their Google Cloud environment nor their data sources.
Any help is appreciated.
This is not supported by Google Data Studio.
In short, if you can't make your report public, and you can't authenticate to view it, you're out of luck.
The link you provided is much more a hack than a feature. It suggests you to make your data public with a custom authentication mechanism developed in a Community Connector that requires a token as parameter.
This way, your report will be available to anyone, however, since your report requires the token to work (a kind of password), it won't show any data to unauthorized users (those who don't provide a valid token).
Although it is possible, I think it requires so much effort to make it work, and, of course, it requires that you change the connector of your report. So 'yes', you need to own the report to connect to your data through the suggested Community Connector.
Can someone help me in generating a access-token for Stormpath.
I'm following the steps mentioned storms api doc.But stuck with error code 404(The requested resource does not exist).
I'm using end point (http://api.stormpath.com/v1/oauth/token?grant_type=client_credentials) to get the tokens and passing all HEADER values as mentioned in API document. Have some used it before ?
I work at Stormpath and can help you with this.
The answer is that you need to use one of our SDKs on your server. At this time we don't support token creation directly from our API. Instead you will need to expose this functionality on your server by using one of our SDKs. The SDK will work with your Stormpath Application to create the tokens and serve them from your serve.
This section of the documentation has examples:
http://docs.stormpath.com/guides/api-key-management/#using-the-stormpath-sdk-to-authenticate-and-generate-tokens-for-your-api-keys
Hope this helps!
Recently I was asked to add an XML API to one of the Symfony modules in my project. I did it, and it works well. For authentication, we use sfGuardPlugin. Symfony version is 1.3.11. Using Propel, not Doctrine.
The most recent request to me is this:
We will embed a Flash game into the website.
The Flash will do requests to the XML API.
The guy who is coding the Flash application says that it doesn't share cookies with the browser.
We want the Flash to be able to reuse the session of the currently logged in user (we won't allow to be even shown if no user is logged in).
I did try this would-be solution: (taken from other SO articles and various Google search results)
I was told that the Symfony session resides in the symfony cookie.
I was told that if I copy this value in another client (in my case, wget) and do session_id("stolen_session_id") I will be able to duplicate the session, have the same user logged in, etc.
This turned out to be wrong. Say my cookie symfony had the "blabla" value. I did this: wget --post-data='session_id=blabla' X.X.X.X:NN/api/bla.xml -O-. My server PHP code parses this POST parameter and feeds it to session_id function. It then reported in the logs that the session_id('blabla') was returning 1. However, calling $this->getUser()->getGuardUser() returns null.
I need a way to map a passed session_id to a valid sfGuardUser. Or find an alternative way of reusing a session which already exists.
Suppose I have full access to the cookies. I want to know which one of them (or all of them?) to duplicate in order to achieve this.
BTW, I am seeing in my Chrome dev tools that the symfony cookie is of a session type. So it's no wonder at all as to why my method doesn't work, but I am little lost as to how do I do this in Symfony, while using the sfGuardPlugin.
I do realize this is not one of the most informed questions, but ditto, I just need help.
Thanks for your time.
(Dimitar P.)
Oops, forgot to mention which cookies I see on my domain:
symfony
sfRemember
__utma
__utmb
__utmc
__utmz
I am guessing the last four are for Google Analytics, though.
I didn't want to do this, but I was unable to find other alternatives:
$ wget --header='Cookie: symfony=blabla' X.X.X.X:NN/api/bla.xml -O-
I wanted my XML API to be REST, but evidently, Symfony doesn't allow authenticated requests other way than using cookies (and to enable the session ID to be always included in the URL is not an option at all).
Still, if somebody shows up with a fully REST alternative, I will upvote his/her answer.
You will need some way of specifying which user is executing the (wget) request. And PHP sessions use a session ID by default.
A common way to do this is token-based authentication. The most common way to achieve this is OAuth, which has a lot of default libraries (both for Symfony and for your API consumers).
If you're the only one using this API, you can also create a custom token (random sha1 string) per user per session (you can store this somewhere in your database). Now you would create something like ` wget X.X.X.X:NN/api/bla.xml?token=asdfhdsfhf