Do you need to hide your Firebase API keys for Ionic apps?

First Published: 6 September 2017
Updated on: 24 September 2018

Firebase API Keys

About 3 or 4 times a month someone asks this questions, they are worried that since Ionic apps are client-side code (HTML, CSS, JS), someone can see their Firebase credentials and mess with their data.

I understand why this is a concern. People want to keep their data private (ALL OF IT!). But there’s one thing we need to know about Firebase API keys.

The fact that someone knows your apiKey is not a security risk alone (more on that later). The apiKey primarily identifies your Firebase project.

Knowing your apiKey doesn’t mean people can instantly hack all your data, it just means that they can connect to your app/project.

For example:

I have no problem sharing the Firebase apiKey in all of the apps I have in Github, A LOT of people use my apps to test their stuff.

Unless you know my sign-in credentials, there’s nothing you can do to mess with the nodes I use to write my apps on top. You can only use the public part of the app, the part you’re allowed to use.

How do you secure your data?

Remember when I said:

The fact that someone knows your apiKey is not a security risk alone (more on that later)

It’s because we don’t get all this protection by default, we have to make it work by ourselves. To do that, we need to set up a few things:

Security Rules:

These type of rules break down into two groups:

Validation rules: This makes sure that all the data is what you want it to be, and the structure of the data follows the structure you want, for example.

  • A field can only be a string.
  • A field can’t have child nodes.
  • A field can be created new but not edited.
  • etc.

They ensure that all of the data that eventually gets stored in your database follows the structure and patterns that you want.

Authorization Rules: This is more about WHO can see or modify the data that’s stored in the database. For example:

  • Making sure a user’s profile is only visible to the user who created it.
  • Ensuring that only logged-in users can access the database.
  • Securing a node so only a few set of users can see it or edit it.
  • Setting up your database to be read-only and only allows yourself to write or create new data.

If you set those up correctly, you’ll help your app avoid the most common type of attacks.

Firebase APIs

Firebase APIs (Push Notifications, Analytics, Cloud Functions, etc) won’t work for attackers because most of those require you to use your Google and iOS certificates.

For example:

When you add push notifications to a project, you need to create the app inside your Firebase app (inception!) that app has all of the info, like package name, store name, etc.

If someone tries to use the different info in their app to access your push notification service, it will crash, because it won’t match with the one you created.

Authentication

A common concern is that someone can create an app that looks just like yours with your firebase apiKey to get access to users data (That has nothing to do with your database security, that’s a Phishing attack).

To prevent that whenever you’re using 3rd party authentication (Facebook, Google, SMS), you need to set up allowed domains, allowed redirect domains, app keys, app secrets, etc.

For example:

John Hacker decides to create a copy of your app, adds your Firebase apiKey thinking that if he can get a user to log in, he can have that user’s information, so he sets up Facebook Sign-In and waits for the users.

The problem here is that when you add Facebook Sign-In to an Ionic/Firebase app, you have to create the app in Facebook’s developer console and add that app’s App ID and App Secret to your Firebase console.

It means that every time I user falls for John Hacker’s scam, the app will crash and not let them log in.

API Blockage by Domain and Package

Another cool thing, if you go to your Google APIs account, you’ll see all of your Firebase projects, pick one, and in the Credentials Tab select your API key.

If you’ve never messed with it, it should be called something like Browser key (auto created by Google Service), open it, and you’ll find options for key restriction:

This key is unrestricted. To prevent unauthorized use and quota theft, restrict your key. Key restriction lets you specify which websites, IP addresses, or apps can use this key.

There you can choose HTTP referrers (websites) and add your domain. This means that the Firebase database will only accept requests for people writing from that domain.

Or Android apps and iOS apps, where you can add package name and fingerprints.

For example:

If you build myawesomeapp.com and add the domain in the HTTP referrers (websites) section, any attacker trying to connect from a different domain will get an error, and those requests will never make it to the database.