Mobile app security: what attackers actually do

01The client is not a security boundary

Any check performed only in the app can be bypassed. Feature gating, price calculation, permission checks and validation are all advisory once they run on a device the attacker owns.

This sounds obvious and is violated constantly. The common shape is an API that trusts a parameter the app sends - a user ID, a role, a price, a discount eligibility flag - because the app would never send a wrong one. The app is not the only thing that can call your API.

The correct framing: your API must behave correctly when called directly by a hostile client with a valid token. If that is not true, hardening the app does not help.

02Real threats, ranked

The ranking below reflects what actually causes incidents rather than what appears in scanner output.

• Broken object-level authorisation. Fetching another user's record by changing an ID in the request. Consistently the most exploited and most common finding.
• Secrets in the binary. API keys, signing secrets and third-party credentials extracted by decompiling. Anything shipped in the app is public.
• Insecure local storage. Tokens or personal data written to unprotected storage, readable on a rooted or jailbroken device and often in device backups.
• Weak session handling. Tokens that never expire, are not revoked on logout, or survive a password change.
• Overly broad API responses. Returning a full user object where the screen needs a name, leaking fields the UI never displays.

03What hardening does and does not buy

Certificate pinning, root detection, obfuscation and anti-tampering are all defensible, but they raise cost for an attacker rather than preventing anything. They are appropriate for high-value targets and a distraction for most apps that have not yet fixed authorisation.

Pinning in particular carries operational risk. A pinned certificate that expires or rotates without a matching app release bricks your app for every user until they update - an outage you cannot fix from the server. If you pin, pin to a CA or include backup pins, and treat rotation as a release-blocking dependency.

Root and jailbreak detection is worth having for fraud-sensitive flows and is trivially bypassed by a determined attacker. Use it as a signal, never as a gate on correctness.

04Where to spend first

In order: fix object-level authorisation on every endpoint, remove secrets from the binary, use platform keystores for tokens, and make sessions revocable. That sequence addresses the overwhelming majority of real incidents.

Only after that does client hardening earn its cost. Teams routinely invert this order because hardening is a library you add and authorisation is work spread across every endpoint.