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 have a page on our site that uses Google's reCAPTCHA before allowing the user to download a file.
It works great and we totally stopped all the evil bots from spamming our servers.
Now we want to allow a specific entity (user, domain, whatever) to be able to automatically download files without solving the challenge. Or maybe solving it once per session (which will be longer than 2 minutes) and not once per file.
Is there some way we can issue them a multi-use token or have them get a token from Google that will allow them (temporary?) unfettered access to our file downloads? Can we whitelist their domain in the Google admin settings?
Or is this something I need to build myself?
EDIT: It turns I didn't get all the requirements for this assignment. Whitelisting will not satisfy the requirements since it is apparently multiple entities, and that will indubitably change in the future.
reCAPTCHA does not provide specific whitelisting for users or domains.
Instead, you should be looking at making this dynamic on your side. For example, disable reCAPTCHA for signed-in users or generate a token on your server with an expiry time, set that as a cookie on the client, and disable reCAPTCHA for valid tokens.
I am applying spring security to a web application where i need to do the following:
Limit access to certain pages for certain roles/authorities
Limit access to certain data based on user access and user role (for
example admin can see all data, a user can see only data on which the admin granted access for the user)
Allow actions on data based on the access right the user has (read,
manage, etc)
So, i was thinking:
Limit access to certain pages for certain roles/authorities -> use
hasRole
Limit access to certain data -> filter directly in the queries
getting the principal from the security context
Allow actions on data based on the access right the user has -> use
my custom PermissionEvluator's hasPermission method
Now this is a setup i came up with, but would like to know if this makes sens and if it is according to a good use of the spring security framework or am i simply twisting it too much.
Spring security provides all these features and makes implementing these features simple. Yes your approach is right. you can add below cases.
security none: allow unauthenticated users access to certain
pages.(login, public pages) authenticated: allow access to
authenticated users.. (general access to all registered users)
restrict based on role: readonly, editor/manager, based on
permissionEvaluator on the data user has access to
You can also use spring security to protect your web application against malicious users with features like
- CSRF protection (enabled by default)
- XSS protection
for further detail read: spring security manual
How can i create a role for a user to access only dashboard tab to monitoring the graphs in kibana4 using shield?
The role must satisfy the below conditions
-The role must not have access to Discover tab,Visualize Tab and Settings tab.
-The role must have access to dashboard tab only.
Is this possible in Kibana4 with shield
According to this article, it is not currently possible with Shield:
Kibana and Shield do not currently provide a way to control which users can load which dashboards.
There is the issue #4453 that you might want to follow, if you're interested in how they will be solving this (and you can +1 it, too)
You can still protect your dashboard using either Apache or Nginx. See this discussion and this one.
I want to provide access to address books and calendars that may have search filters (e.g. tags, user, groups) applied.
They should not be auto-discoverable because there may be billions of combinations but must nonetheless be compatible with common clients (e.g. iOS / OS X, Windows Phones), i.e. it should be possible to add the URL with filters to the client.
One issue seems to be that some clients rely on discovery features rather than the URL you give them, e.g. iOS (you try to add one address book by exact URL and it adds all discoverable ones instead).
Another thing is structuring the optional filters.
What about using paths?
What is considered best practice here?
Are the calendars readonly or readwrite? If they are readonly, you can use webcal URLs for calendars (aka 'subscribed calendar' or iCalendar-over-HTTP).
For Cal/CardDAV calendars the Apple devices (and most other DAV clients) configure a full account (using the regular account discovery mechanisms), not just 'a URL'. I don't think there is a way around this.
Assuming you are building a web service which provides a registry/search-engine or which is an aggregator of such calendar or address data, this service could then provide Cal/CardDAV accounts (which implements the discovery).
On your web-service you would then have two options:
proxy (and potentially cache) the remote data
create a 'CalDAV subscribed calendar' (a special WebDAV resource which points to a CalDAV calendar (resource type {http://calendarserver.org/ns/}subscribed)).
For contacts you only have choice 1. And as an extra complication you might want to expose the stored queries as vCard groups instead of CardDAV collections. This is because some clients (i.e. some MacOS Contacts apps) only support one CardDAV collection (and only use groups to structure the data).
Sample: Lets say you invented a service called 'Caloogle.com'. The user needs to get some account on that service (could be auto-created, etc). The user adds a CalDAV account to his iOS device (e.g. using a preconfigured profile, so that he doesn't have to enter all the data), which then connects to Caloogle to fetch data into the iOS EventKit database.
Now in your Caloogle app (or on the website), you let the user search for calendar data. If the user found a set he likes, he saves that as a calendar into Caloogle, say 'Dividend Release Dates BP, Apple and AlwaysRightInstitute'. iOS will ping the account eventually and pick up the saved calendar. User is amazed and happy.
How you actually implement the web service (proxy or name-to-url map) depends a lot on where your data is coming from ...
Makes sense?
P.S.: Be careful when storing queries in URLs, some HTTP infrastructure components have limits on the length of a URL, and advanced queries can quickly overflow this.
Like hnh said in his answer, smart clients will try to discover the DAV services you are offering when you configure CardDAV or CalDAV from a URL rather than just use that very URL, so there seems to be no clean way to provide multiple virtual collections filtered by tags, users, groups etc.
The simplest solution that could work is to provide one virtual DAV server for each filter URL, with full service discovery within the constraints of that filter URL.
Virtual endpoints are provided with the help of URL rewriting, a feature found in common web servers, and will all point to the same DAV server code base and supply it with the filter criteria.
If for example, you want CalDAV / CardDAV collections of items that have the tags PR and Spain, you could expose them under https://dav.server/tag:PR/tag:Spain/, while items with a tag China can be exposed under https://dav.server/tag:China/.
Note that each URL provides full DAV functionality with discoverability.
As discovery is relative to the respective roots https://dav.server/tag:PR/tag:Spain/ and https://dav.server/tag:China/, there will be no interference.
Additionally, you could expose a simple URL https://server for a well-defined set of CalDAV / CardDAV collections, e.g. a default calendar / address book or some "bookmarked" collections defined by the user in some way, e.g. "PR Spain".
The simple URL would then provide these HTTP redirects, as per RFC 5785:
https://server/.well-known/caldav => https://dav.server/default
https://server/.well-known/carddav => https://dav.server/default
iOS clients and those supporting well-known URIs could then be configured by just setting the host to server and supplying login credentials.
They would then try to connect via HTTPS, check for the well-known URIs and thus discover the DAV endpoint at https://dav.server/default.
Those without well-known URI support nor discovery would require the exact URL, e.g. https://dav.server/default/calendars/jane/main or https://dav.server/tag:China/calendars/jane/main.