Do you need to hide your Firebase API keys for Ionic apps?
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
identifies your Firebase project.
apiKey doesn’t mean people can instantly hack all your data, it just means that they can connect to your
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
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.
By the way, do you want to jump-start your development using the Firebase modular SDK with AngularFire?
Download my free book that will take you from creating an app to properly using Firebase Auth and Firestore.
How do you secure your data?
Remember when I said:
The fact that someone knows your
apiKeyis 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:
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.
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 (Push Notifications, Analytics, Cloud Functions, etc) won’t work for attackers because most of those require you to use your Google and iOS certificates.
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.
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.
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.
Android apps and
iOS apps, where you can add package name and fingerprints.
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.