[MUSIC PLAYING]
PETER FRIESE: Hey there.
My name is Peter.
ROSALYN TAN: And I'm Rosalyn.
In the last episode of "Better Safe than Sorry,"
Rachel and Sam showed you how to limit access
to your application's data by using Security Rules.
Security Rules are a key feature of Firebase authentication,
and help you to make sure users can only
access their own data that is stored
in Cloud Firestore, Cloud Storage, or the Realtime
Database.
Security Rules play an important role in keeping your users
and their data safe and secure.
PETER FRIESE: But trying to read or manipulate your users' data
is not the only way someone can attack your application.
Another attack vector is traffic, specifically traffic
that's not from real users.
Usually, more traffic is better.
It means more users are using your app,
or your users are using your app more.
But sometimes, more traffic is not better.
And today, we will discuss why some traffic might actually
be unwanted and what you can do about it.
Let's look at this architecture diagram from the first episode.
You can see that clients like your application
can directly interact with Firebase services
like Cloud Firestore or Cloud Storage.
This is possible because these services are directly
accessible via the internet.
And this is one of the reasons why it's so easy
to get started with Firebase.
All you need to connect is the route URL of, let's say,
Firestore and your project ID.
ROSALYN TAN: But this also means that anyone
who gets hold of your project ID and API key--
which is not too hard to do in a web app--
can go ahead and poke around on your app's back end
to see what they can find.
Now, I know you're thinking, I've
watched Rachel and Sam's video and implemented all the best
practices for Security Rules.
I'm good.
Well, not quite.
This means a malicious actor will not
be able to harm your users by reading or modifying
any data in Firestore, Realtime Database, or Storage,
but they might still be able to cause
you, the developer, some pain.
PETER FRIESE: Here are some consequences
you might face if a malicious actor probes around
in your app.
If they call your Cloud Functions,
that will cost some amount of money for every invocation.
Your Security Rules might need to read some values
from the database to determine if the caller is
allowed to access the requested data, using get or exist calls.
That also costs a tiny bit of money for every read.
And keep in mind that, in your Security Rules,
you cannot tell a legitimate user apart from a malicious
actor.
Another issue is that someone might
try to saturate your back end by making many calls
in a short period of time.
Firebase has a lot of capacity, so your app will still
be available for your users.
But all those requests will still cost money,
and you might be in for a nasty surprise
at the end of the month.
ROSALYN TAN: Pro tip--
you can set up an alert in the Billing section
of your Firebase project to receive a warning
when the budget you set for your app is exceeded.
PETER FRIESE: That's a very good point.
But on the other hand, if all this traffic is not
coming from legitimate users of your app,
why pay for something that you didn't
ask for in the first place?
And that's why we built App Check.
App Check is an extra security layer
that blocks unwanted traffic from reaching the back end
services of your app.
It works a bit like a shield from sci-fi stories.
When you turn it on, it will inspect all incoming traffic,
and will only let traffic coming from your own apps
pass through to the back end.
No matter if the unwanted traffic
comes from a 12-year-old who has just discovered what cURL is
or a malicious actor who wants to steal your data,
if the request isn't from your app,
they will just get a HTTP 400, bad request.
To be able to tell a legitimate request apart
from someone who is just trying to probe around in your app
using cURL or some other networking tool,
App Check requires all requests coming
from your app to be attested.
This means that someone needs to say,
yes, this request comes from a legitimate app.
So you could say that Firebase authentication is
for authenticating users and Firebase App
Check is for authenticating applications.
ROSALYN TAN: OK, so how does App Check work?
How can you authenticate your app,
and how does App Check know that traffic coming from your app
is legitimate?
Let's first look at this diagram.
Here, we see your app's back end protected by App Check.
And here's a legitimate client app.
To prove it is legitimate, it sends an App
Check token with each request.
The App Check layer on the back end verifies the token
and lets the request pass through if the token is valid.
To create an App Check token, your app
uses a so-called attestation provider
that you can set up in the Firebase Console
and integrate into your application code.
Now let's take a look at what happens if an illegitimate app
tries to access your back end.
Since the illegitimate app doesn't have an attestation
provider registered with your back end,
it won't be able to obtain a valid App Check token.
Since it doesn't have this information,
this app cannot attach a valid attestation token
to your request it sends to your back end.
On the back end, Firebase inspects the incoming requests.
It notices that some of the requests
don't have a valid attestation token, so it rejects them.
This effectively prevents an attacker,
or a person who is just probing around,
from accessing your back end in the first place.
PETER FRIESE: Cool.
So now that you have a basic understanding of how
App Check verifies if requests are coming
from a legitimate app, let's take a quick look
at how you can enable App Check for your project.
There are three steps.
First, you need to configure App Check for your project.
In this example, we want to enable App Check for an iOS app
that is already part of our Firebase project.
To do this, we will go to the App Check page, select our app,
and then choose one of the attestation providers.
We will use App Attest, as this is the easiest to set up.
You just need your team ID.
This is your iOS development team ID.
And you can find it in your Apple Developer account.
Second, once you've done this, go into your Xcode project
and enable the App Attest capability.
This will produce an entitlement file
in the root folder of your project.
Open this file and turn on production mode.
Third, then go into your app delegate or the
at main entry point of your app, and add the following line
to initialize App Check when your app starts up.
And that's all you need to do to prepare your app for App
Check in your iOS app.
The only thing left to do is actually
enforcing App Check in the Firebase Console.
ROSALYN TAN: So when should you start enforcing
App Check in your app?
Keep in mind that once you enforce
App Check for your project, all requests
need to have a valid App Check token in their headers.
Otherwise, they will be rejected by App Check on the back end.
This is absolutely what we want for any new application.
But if your application is already
installed on hundreds, or thousands, of your users'
devices, you want to avoid a situation where
some of your users can't access your app because they're
using an older version of the app that doesn't
make use of App Check yet.
So what's the best moment to flip the switch
and enforce App Check?
Well, ideally, when all or at least most of your users
have the new app version installed.
But it's hard to tell when most of your users
have installed the most recent version of your app.
To make this a little bit easier for you,
we've added a little dashboard to the Firebase Console.
This dashboard shows all the requests
coming into your back end and how many of them
are verified by App Check.
Here, you can see how many requests are verified,
how many might be coming from older versions of your app, how
many are missing the App Check token header in the request,
and how many have an invalid App Check token attached.
So by looking at this dashboard, you
can decide when is a good time to enforce App Check.
If most of your requests are coming
from the unverified, outdated client category,
you'll probably want to hold off on enforcing
App Check until more of your users have updated.
However, if a lot of requests are
coming from the unverified, unknown origin
or unverified, invalid categories,
this is a good indication that you have malicious traffic.
And you'll want to enforce App Check to block this traffic.
If you start working on a brand-new app,
we would recommend adding App Check right from the beginning
so you can enforce App Check right from the start.
PETER FRIESE: One thing to keep in mind.
Some attestation providers have quotas
for the number of daily calls you can send them.
So if you suspect you might be onboarding a lot of new users,
consider using Remote Config to gradually roll out
the use of App Check to your users.
Our documentation has more information
about the quotas and limits of the attestation
providers for your platform.
ROSALYN TAN: In the previous step,
we configured App Check for the Realtime Database.
But other Firebase products support App Check as well.
You can use it with the Realtime Database, Cloud Storage, Cloud
Firestore, and Cloud Functions.
You can even use it with your own custom back end that
doesn't even run on Firebase.
So let's take a quick look at how to use
App Check in Cloud Functions.
You can call Cloud Functions from your client application,
or from other Firebase products on the back end.
For example, you can call a Cloud Function
whenever a new user signs up for your app
or when someone creates a new document in Cloud Firestore.
We call these triggers.
And as they are called from another Firebase service,
we can safely assume that they come
from a trusted environment.
However, when calling a Cloud Function from a client app,
we can't trust this as much.
Remember, someone might have your API key
and may try to probe your back end.
To protect callable functions using App Check,
we need to add a few lines of code
to the beginning of those functions.
If a request sent from your client
is verified by App Check, there will
be an additional field in the context object of the call.
To check if the request is verified,
you can check for the presence of context.app.
If this is undefined, the request is not verified,
and you should return an error.
PETER FRIESE: Let's finally look at how
you can use App Check with your custom back end.
For example, you might run a content management system
on your own server, and you want to make sure
that only your genuine apps can communicate with this CMS.
There are two things you need to do.
Firstly, send a valid App Check token
with every request from your client apps,
and secondly, verify the App Check token in your back end
code.
Let's take a look at the client code first.
After you get a fresh App Check token from the App Check client
SDK, you add it to a header of your request.
Here, we are using X-Firebase-AppCheck,
but you can use any name you want.
It is best practice to start custom header
names with X minus to avoid collisions
with existing header names.
On the server, you can then extract the header field
from the request and verify if it's valid.
If the token is not present or invalid,
you should return a HTTP status code 401.
This indicates that the client request has not
been completed because it lacks valid authentication
credentials for the requested resource.
Using these two steps, you can protect your back end
from malicious actors using App Check.
ROSALYN TAN: So today, you learned
how to use App Check to protect your back end.
Let's summarize.
App Check and Security Rules are two security features
in Firebase that help you to protect
your app and your users' data.
They might sound similar, but they serve different purposes.
Security Rules make sure users can only access the data
that they are allowed.
For example, you can use Security Rules
to make sure users can only read and write their own tasks
in a to do list app.
App Check has a different goal.
Its purpose is to protect your back end
from any unwanted requests.
This protects you from nasty surprises
at the end of the billing period.
By enforcing App Check, you block
all requests that don't come from your genuine app.
When building a new app, you should turn on App Check
as soon as possible, preferably before you have real users.
If you want to add App Check to an existing app,
you can use the App Check dashboard in the Firebase
Console to see when most of your users use a version of your app
that supports App Check, and then enforce App Check.
App Check supports Realtime Database, Cloud Firestore,
Cloud Storage, Cloud Functions, and even your custom back end
resources.
We will add support for more Firebase and Google services
in the coming weeks and months.
PETER FRIESE: Awesome.
App Check and Security Rules are two important tools
that help you keep your app and your users safe and secure.
Next time, we're going to talk about passwords, and why
using email and password authentication
might not be the best way to onboard new users.
Thanks for watching and stay safe.
[MUSIC PLAYING]