What is the purpose of Firebase AppCheck?

Question

I want to improve the security of my application and I'm looking into the Firebase App Check service which ensures that all requests made to the server come from my application. Only in Firebase Realtime Database I put the following rules:

"Users": {
      "$userId": {
        ".read": "auth != null && $userId === auth.uid",
          ".write": "auth != null && $userId === auth.uid", 
      }

Which I think ensures that the requests come from a user logged into the application.

So what does App Check do more, does the service also block jailbroken or specially rooted devices? Because it says on the site: Requests originate from an authentic, untampered device. But nothing in the introduction explicitly mentions what tampered means even if it seems logical I'd rather make sure.

So how does AppCheck ensure that the data sent to the database is not corrupted ?

For example if data persistence is enabled and the user closes the application, changes the locally stored query and restarts the application. Then in my opinion the corrupted request will be sent and authenticated by AppCheck, yet it will have been modified. If not, can you detail the process as I am a bit confused.

Paquin

Answer 1

If you have just the security rules you show, and don't use App Check, anyone can take the configuration data from your app, and make API calls with that data. So they can call the API to create a user account, and make calls to the database in ways that you may have not imagined.

If your security rules capture all the requirements you have about your data, then App Check indeed doesn't change anything about what a malicious user can do, and it's just an extra layer to deter abusers.

In many cases though, there are (sometimes subtle) differences between what your application code does and what your security rules enforce. In cases like those, an abusive user may run their own code and do something different than your code does.

For example, your security rules don't enforce anything about what data can be written. So an abusive user could:

• not write data that your code expects in the user profile.
• write completely different data in the user profile that your code does not expect.
• write much more data into the profile, which your project would then be charged for.

While you can (and should) encode all such requirements around data format and data size into your security rules, enabling App Check is a quick way to already deter many malicious users.

Between using App Check and Security Rules you have both broad protection, and fine grained control over who can access the data and what they can do to it.

Cicisbeo

Thank you for your reply. There are still a few things I don't understand, in the current state of my rules and without having AppCheck a user cannot call the API to create a user account. Because if he does, without being on the application, then the Auth object of the security rules will be NULL right? – Paquin

That's why I don't understand the usefulness of AppCheck, here I don't see what this service would bring to my rules. Unless it also prevents specially rooted, jailbroken devices from making calls. I would like to know what AppCheck allows me to counter as a fraud attempt. – Paquin

Why do you think the user can't create an account outside of your app? E.g. what is keeping them from calling the API from a piece of JavaScript code they write? And if they then access the database, the auth object will be populated - as they are indeed signed into Firebase and (without App Check) there is no way to distinguish the call from your Swift code from the call coming from the JavaScript code that you didn't write. – Cicisbeo

Okay, I'm starting to understand. Tell me if I'm wrong, the user creates a third party script with my database information file, authenticates to FirebaseAuthentication with the appropriate methods but all outside of my application. He can then write whatever he wants in his fields because he has indeed registered with Authentication. – Paquin

But I still have two final questions. How does the user access the information file in my database, it can't be totally hidden? And going back to the offline features of FirebaseRealtimeDatabase, a malicious user could go offline, send queries that will then store locally while waiting, exit the application, modify the stored queries and finally log back into the application. The corrupted queries will be sent because the user is on the application at the time. – Paquin

Clearly I may have a wrong view, this is my first real project and I'm just starting to discover the security issues. So I'd like to know if it makes any difference if the requests are logged even when the application is closed because maybe a user can change them while the application is running and thus bypass AppCheck. So if this is possible, is it necessary to have a special root such as a jailbreak to be able to modify this data during the execution. And if it's mandatory, does AppCheck handle device integrity as the doc says: Requests originate from an authentic, untampered device. – Paquin

I'm sorry not to let you go, but this is a very interesting subject and, moreover, central to my application. – Paquin

It is definitely an interesting subject, but it's hard to fully discuss in comments here. If you think you've found an abuse vector, I recommend giving it a try. If you can indeed bypass the security measures, please report as described here: google.com/about/appsecurity – Cicisbeo

Answer 2

In addition to the answer from puf, check out the WWDC talk Mitigate fraud with App Attest and DeviceCheck. Firebase App Check provides the server for App Attest.

Stockyard

Thank you, it was very interesting ! – Paquin

Answer 3

Go To Apple Certificates, Identifiers & Profiles : Select Your Key Upload firebase and Make Check For : Access the DeviceCheck and AppAttest APIs to get data that your associated enter image description here

Melodrama