119

Firebase provides database back-end so that developers can focus on the client side code.

So if someone takes my firebase uri (for example, https://firebaseinstance.firebaseio.com) then develop on it locally.

Then, would they be able to create another app off my Firebase instance, signup and authenticate themselves to read all data of my Firebase app?

rattanak
  • 1,498
  • 2
  • 13
  • 17

3 Answers3

132

@Frank van Puffelen,

You mentioned the phishing attack. There actually is a way to secure for that.

If you login to your googleAPIs API Manager console, you have an option to lock down which HTTP referrer your app will accept request from.

  1. visit https://console.developers.google.com/apis
  2. Go to your firebase project
  3. Go to credentials
  4. Under API keys, select the Browser key associated with your firebase project (should have the same key as the API key you use to initialize your firebase app.)
  5. Under "Accept requests from these HTTP referrers (web sites), simply add the URL of your app.

This should only allow the whitelisted domain to use your app.

This is also described here in the firebase launch-checklist here: https://firebase.google.com/support/guides/launch-checklist

Perhaps the firebase documentation could make this more visible or automatically lock down the domain by default and require users to allow access?

ROMANIA_engineer
  • 54,432
  • 29
  • 203
  • 199
prufrofro
  • 1,477
  • 1
  • 11
  • 12
  • 2
    when I go the Google API console, I don't see the option to lock down HTTP referrer. Screenshot will be helpful. thx – rattanak Aug 13 '16 at 17:26
  • Have you tried following the steps above? It should take you right there. For security reasons, I am not going to take a screencap. Remember to look for the browser key. best of luck. – prufrofro Aug 15 '16 at 01:15
  • 6
    What about when using firebase with a hybrid mobile app, using a framework like ionic, how can white-listing work? Any suggestions? – Dinana Sep 15 '16 at 20:22
  • Hm. You should still be able to go to the manager console and whitelist whatever domain your app will be coming from. Have you tried the steps above? Let me know what problems you encounter. – prufrofro Sep 15 '16 at 23:59
  • I added some info on this subject here to further protect your public API key (and your database from reading) : http://stackoverflow.com/a/40962187/1017472 – now Dec 04 '16 at 18:53
  • 2
    @prufrofro Is that working fine for you? Was thinking to do the same thing for an Android app. I wonder why Firebase doesn't cover that in the security section. – steliosf Jun 28 '17 at 01:18
  • Regarding the Auth white listing for mobile apps, where domain name is not applicable, firebase have SHA1 fingerprint for Android apps and App Store ID and Bundle ID and Team ID (if necessary) for your iOS apps. @MScott – Anand Dec 09 '17 at 19:11
  • 2
    @Anand Yes but Firebase does not cover this in the documentation. By default the keys are public and you have to restrict them manully for use only in a specific package name and SHA-1 app certificate. And I was wondering why Firebase does not mention this at all. Is there a catch or something? – steliosf Dec 09 '17 at 20:13
  • @MScott I agree, it was little difficult to find this in the documentation. Its covered in "Launch Checklist" (clarity could have been better though). You can check by answer below with the link. By default, these restrictions are not added, may be because, when you start with the development, you may not have all these info(until you launch your fist version of app) That's probably why this is covered in "Launch checklist" and till launch, its your local host/private domain and probably, you don't have risk of exposing these keys to outside world. – Anand Dec 10 '17 at 00:47
  • What about the "Key restrictions" option? – Qwerty Jul 16 '18 at 13:45
  • We tried to follow this approach but it didn't work for our Android app. Appreciate it if someone can take a look at this [post](https://stackoverflow.com/questions/53942388/firebase-api-key-restriction-not-working-with-android-app-package-name-and-sha1) via which we recorded our issue. – Ruifeng Ma Dec 27 '18 at 09:06
  • Thanks very useful – Alex Raţiu Apr 03 '20 at 20:21
  • 1
    I am surprised that people are suggesting HTTP Referrer as a method for securing firebase. It is a well known fact that HTTP Referrer is very easy to spoof and hijack. You just need any hacking software like Burp Suite or OWASP ZAP and you are ready to go. – Punit Pandey May 30 '21 at 17:14
  • Guys but what if they use proxy than they have the same domain right ? proxy works only in development but they can still clutter up the database right ? – Yuvraj Agarkar Sep 23 '21 at 01:38
  • @PunitPandey I agree with you. I tried it practically now, applied referrer restriction and then tried to spoof it via postman by calling REST API to create auth user and Its working! Does anybody knows how to secure this? – Jaydip Kalkani Oct 15 '22 at 05:47
44

The fact that someone knows your URL is not a security risk.

For example: I have no problem telling you that my bank hosts its web site at bankofamerica.com and it speaks the HTTP protocol there. Unless you also know the credentials I use to access that site, knowing the URL doesn't do you any good.

To secure your data, your database should be protected with:

  • validation rules that ensure all data adheres to a structure that you want
  • authorization rules to ensure that each bit of data can only be read and modified by the authorized users

This is all covered in the Firebase documentation on Security & Rules, which I highly recommend.

With these security rules in place, the only way somebody else's app can access the data in your database is if they copy the functionality of your application, have the users sign in to their app instead of yours and sign in/read from/write to your database; essentially a phishing attack. In that case there is no security problem in the database, although it's probably time to get some authorities involved.

Update May 2021: Thanks to the new feature called Firebase App Check, it is now actually possible to limit access to your Realtime Database to only those coming from iOS, Android and Web apps that are registered in your Firebase 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.

Frank van Puffelen
  • 565,676
  • 79
  • 828
  • 807
  • 5
    not quite the answer I am looking for. Let me ask you in a different way. Suppose I gave you this url to my firebase `https://tinderclone.firebaseio.com/` and `https://tinderclone.firebaseio.com/profiles.json`. They are real firebase database. Can you develop an app off it, making a signup form and login form with email. Since my app allows anyone to register with email, after you registered, would you be able to read all data? I will ask you another question later. Thanks – rattanak Feb 16 '16 at 07:25
  • 4
    That depends on how you secure your database. Simply adding `".read": false` will prevent anyone from seeing the data. You probably want to allow a bit more than that, but it all depends on your use-case. Securing the data is covered in the [Firebase documentation on Security & Rules](https://www.firebase.com/docs/security/). – Frank van Puffelen Feb 16 '16 at 07:53
  • @PunitPandey If you're having a problem with the quota of App Check (or in this case it seems you're referring to the SafetyNet provider), I recommend posting a separate question about that, sharing your code, and the error message you're getting. – Frank van Puffelen May 30 '21 at 22:24
  • @FrankvanPuffelen I don't have any problem. I was just pointing out that the quota limitation on SafetyNet, which is "maximum of 5 requests per minute", makes AppCheck pretty much useless for production use. Here is the details on quota - https://developer.android.com/training/safetynet/attestation#quota-monitoring – Punit Pandey May 31 '21 at 10:25
  • That is the number of requests that a single app can make per minute. App Check only makes a single request to Safetynet to get a token, that is then valid for an hour, so you should not bump into this quota. But bugs are always possible of course, so if you're having an issue, I recommend posting a new question with details about that problem. – Frank van Puffelen Jun 01 '21 at 14:12
7

Regarding the Auth white-listing for mobile apps, where the domain name is not applicable, Firebase has

  1. SHA1 fingerprint for Android apps and

  2. App Store ID and Bundle ID and Team ID (if necessary) for your iOS apps

which you will have to configure in the Firebase console.

With this protection, since validation is not just if someone has a valid API key, Auth domain, etc, but also, is it coming from our authorized apps and domain name/HTTP referrer in case of Web.

That said, we don't have to worry if these API keys and other connection params are exposed to others.

For more info, https://firebase.google.com/support/guides/launch-checklist

gignu
  • 1,763
  • 1
  • 14
  • 24
Anand
  • 9,672
  • 4
  • 55
  • 75
  • Pardon my ignorance, I'm not very good with encryption but isn't Sha1 accessible through your apk? Can't people just copy the Sha1 too? I don't see how this helps. I would be very happy to be proved otherwise :) – cs guy Sep 22 '20 at 03:09
  • Yes. You can certainly get sha1 of a apk. But that's not something you pass as a param to firebase to validate your call. It's is taken by firebase at it's api-sdk level (believe from android runtime) . So you won't be able to send this to firebase as a param to fake the connection. – Anand Sep 22 '20 at 04:12
  • 1
    Using SHA1 fingerprint only will not help anything to secure your Android app communication with Firebase. The SHA1 itself can be obtained and copied easily, and the connection can still be faked by using Firebase API instead of the SDK. You should attest your app first, and use some code obfuscation to hide the key. – FEBRYAN ASA PERDANA Oct 14 '20 at 15:39