A Client You Cannot Control

A mobile app runs on a device you do not own and cannot trust. Users can root or jailbreak it, run instrumentation frameworks, and inspect everything the app does. Mobile application security assumes the client is hostile territory and designs the backend so that client compromise does not become a data breach.

The Security Model

The fundamental rule: never trust the client. Anything the app enforces—licensing, feature gates, access control—can be bypassed on a compromised device. Sensitive authorization must happen server-side. The app is a presentation layer; the server is the source of truth.

OWASP MASVS Domains

The Mobile Application Security Verification Standard organizes concerns into domains worth knowing:

  • Storage: where and how data is kept on the device.
  • Cryptography: correct use of crypto primitives.
  • Authentication: session and credential handling.
  • Network: transport security and API communication.
  • Platform interaction: use of OS security features.
  • Code quality: resilience and error handling.
  • Resilience: anti-tampering and reverse-engineering resistance.

Insecure Data Storage

A common flaw is sensitive data left in plaintext:

  • Tokens, passwords, or PII in SharedPreferences, NSUserDefaults, SQLite databases, or log files.
  • Data cached in world-readable locations or written to external storage.
  • Credentials surviving uninstall or backup.

Store secrets in the platform's secure storage—Android Keystore and iOS Keychain—which are hardware-backed on modern devices. Avoid logging sensitive data, and encrypt anything that must persist.

Transport Security and Pinning

All traffic should use TLS with certificate validation enabled. Many apps disable validation during development and ship it that way, enabling trivial interception. Certificate pinning binds the app to a specific certificate or public key, defeating man-in-the-middle proxies—but pinning must include backup pins and a rotation plan, or an expired pin bricks the app.

Authentication and Session Management

Mobile session handling has unique pitfalls: tokens stored insecurely, refresh tokens with excessive lifetimes, missing server-side revocation, and "remember me" flags that never expire. Use short-lived access tokens with refresh, bind tokens to the device where possible, invalidate server-side on logout, and support remote session revocation.

Reverse Engineering and Tampering

Attackers decompile apps to find API keys, endpoints, hidden features, and business logic. Obfuscation (ProGuard/R8, content encryption) raises the cost. Integrity checks detect rooted devices, modified binaries, and debugging, and can trigger a degraded mode—but never a purely client-side security decision, since all checks can be patched out. Root/jailbreak detection is useful telemetry, not a guarantee.

Server-Side Defenses

Because the client is untrusted, put real controls on the server:

  • App attestation: Google Play Integrity (Android) and Apple App Attest/DeviceCheck confirm requests come from a genuine, unmodified app on a genuine device.
  • API authentication and rate limiting independent of the client.
  • Server-side validation of every input and every business rule.
  • Certificate pinning on the API side where clients support it.

Testing

Assess mobile apps with both static analysis (decompilation, secret scanning) and dynamic analysis (instrumentation with Frida, traffic interception with mitmproxy). Test on rooted/jailbroken devices because that is the environment attackers use. The goal is not to make the app unbreakable—it is to ensure that breaking the client yields no data or capability that the server should protect.