Anything your mobile app checks on its own, such as a premium flag, a role or an input rule, can be changed by someone who controls the device. The rule of thumb from OWASP is to enforce authentication and authorization on the server and assume client-side checks can be bypassed.
What the guidance says
MASVS-AUTH-1 states that while enforcement of authentication and authorization mechanisms must be on the remote endpoint, the app also has to follow best practices for the protocols involved. The OWASP mobile cheat sheet says it more bluntly: enforce on the server, load user data onto the device only after login, and duplicate client-side checks on the server.
The reasoning is simple. The app is code on a device that belongs to the user. They can inspect it, change it, replay its traffic or write their own client that talks to your API. Your server never talks to "the app". It talks to whoever sends valid-looking requests.
What breaks when the server trusts the client
- Premium or paid features unlocked by a local flag. Change the flag, get the feature.
- Role or permission shown in a token the server does not verify. Edit the value, become an admin.
- Price or quantity sent from the app. The server accepts what it is told.
- Object IDs in requests. If the server does not check that the user owns the object, changing the ID shows someone else's record.
- Rate limits applied in the app. A custom client ignores them.
- Validation done only in the form. MASVS-CODE-4 asks that the app validates untrusted inputs, but your backend must validate too.
A short review for any endpoint
- Who is calling? Is the token verified on the server for every request?
- Are they allowed? Does the server check the permission for this specific object and action?
- Is the data valid? Does the server validate type, range and relationships, rather than trusting the form?
- Can the client change a price, a role or a status? If the server accepts it, it must also be allowed.
- What happens at scale? Are there limits per account on the server?
For the authorization part, see deny by default authorization.
What client-side checks are still for
They are not useless. They give users fast feedback, avoid pointless requests and make the interface behave sensibly. They just are not security controls. Write them for usability and write the server rule for safety.
Device-side defenses, such as local authentication (MASVS-AUTH-2) and resilience controls, raise the cost of attack but do not change this rule.
Mobile specific points
- Do not store user passwords on the device. The cheat sheet recommends revocable, device-specific tokens instead.
- Do not rely on spoofable identifiers.
- Allow remote logout and expire sessions after inactivity, enforced by the server.
- Require re-authentication for sensitive actions such as password or payment changes.
Quick check
Can obfuscation protect a client-side check?
It makes the check harder to find, not impossible to bypass. Do not rely on it for authorization.
Is it fine to hide a button for users without permission?
Yes, as usability. The server must still refuse the request.
Sources
Last reviewed: 19 October 2026.
