Do firebase auth tokens or firebase app-check tokens protect my backend against external request of "legitimate" users?

Question

I am wondering about the security of my mobile app. I want to avoid the case where "legitimate" users (i.e. users that have a real account on my app) copy their tokens to spam arbitrary requests to my backend. Here is my setup:

I have a Firebase cloud function backend and a react-native mobile app frontend. Users that are authenticated on the frontend using firebase auth get an ID token. They can use this token to make requests to the cloud function. The cloud function checks the ID token's validity and then processes the request.

The ID token provides little protection against "legitimate" users. A user can just copy their ID token (e.g. using a rooted phone) and use it to send arbitrary requests with e.g. curl. The ID token will expire at some point, but I suppose the user could just copy the refresh token as well and then automatically refresh their ID token.

Firebase also offers an "app-check" that supposedly checks if the request was sent from my app on a real android device. However, as I understand it, all that app-check does is create another token which is then passed on to the backend and verified there. While this might offer some protection for the user, it faces the same problem as the ID token when it comes to preventing spam from "legitimate" users.

As I see it, these security measures are not meant to protect my backend against arbitrary requests of legitimate users. Rather they protect the user (which is great, but besides my point here). If I want to prevent spam, I would need to implement something like a rate limit on my backend. Is this assessment correct, or am I mistaken? Is there some way the app-check token prevents the user from just copying the token?

Answer 1

If someone has physical access to a hardware or device that has stored in its memory a valid token, we can guess/assume/think this person was authenticated by the system as a valid operator, so he can execute whatever operations is allowed.

I totally agree with your ideas of adding more layers and checks in order to increase safety.

If your business has high levels of data safety requirements, then you should implement features like:

• issue tokens for a specific device, by attaching an unique ID of the client hardware/software and associate this hash with the issued token;

• reduce token expiration time;

• invalidate the token if someone tries to use the same token from different devices;

• Implement two factor authentication and check periocally for user codes;

• Add request limits/throtling at API level; rate-limit, debouncing, limit size of output data;

• Use code obfuscation/cryptography/minification during build;

• Add auditing logs on relevant function calls in your business logic;

• Identify possible suspect behavior by monitoring your logs, create alerts and plans for acting against suspicious users.

• captchas

• always enforce HTTPS protocol

• Cookes Security and HTTPOnly

• Avoid storing sensitive data in local storage

• Prevent XSS atacks by implement XSSRF validation

• Use a proxy backend with CORS setup correctly and secury including Policy recommendations

Software Security/Data safety is a permanent challenge and hackers/crackers will invest time and energy in the same proportion they valuate your data.

EDIT:

I recommend reading all these excelent articles from

JWT Token Handler Pattern

SPA using the Token Handler Pattern

Mobile Dynamic Client Registration

Spa using Token handler sample

JWT Security Best Practices

These sites has inumerous good resources to read and learn