The Mobile App Security Testing Checklist Every Team Needs
From insecure local storage to weak session handling, these are the mobile app vulnerabilities we find most often — and how to test for them.
Mobile applications get tested less rigorously than web applications far too often, usually because teams assume the app store review process or OS-level sandboxing already handles security. Neither does. App store review checks for policy compliance, not authorization logic, and sandboxing protects the device from the app — not your backend from a malicious or reverse-engineered client.
The device is not a trusted environment
Any assumption that client-side logic is safe from tampering should be treated as false by default. A sufficiently motivated attacker with physical or emulated access to a device can decompile the app, bypass client-side checks, and interact with your backend directly — meaning every security control that matters must be enforced server-side, with the app treated as a convenience layer rather than a trust boundary.
We routinely demonstrate this by bypassing "premium feature" gates, jailbreak/root detection, and even client-side input validation entirely, simply by intercepting and modifying traffic before it reaches the backend.
Insecure local storage remains extremely common
Authentication tokens, API keys, and personally identifiable information are still frequently found stored unencrypted in shared preferences on Android, plist files on iOS, or local SQLite databases either app uses for caching. Developers often assume the OS sandbox is sufficient protection, forgetting that a lost or compromised device, a malicious app with excessive permissions, or a simple backup extraction can expose that data entirely outside the app's intended flow.
The fix is straightforward in principle — use platform-provided secure storage (Keychain on iOS, EncryptedSharedPreferences or the Keystore system on Android) for anything sensitive — but it requires a deliberate review pass, since insecure storage rarely triggers any functional bug that would surface it during normal QA.
Certificate pinning and transport security
TLS alone protects traffic from passive network eavesdropping, but it does not protect against an attacker who can install their own certificate authority on a test device — which is trivial with tools like Burp Suite or mitmproxy. Without certificate pinning, an attacker can intercept, read, and modify all traffic between the app and its backend, effectively defeating the encryption entirely from a security-testing perspective.
We find pinning either missing, applied inconsistently across app versions, or implemented in a way that can be bypassed with well-known runtime hooking frameworks — all of which we specifically test for, since a pinning implementation that only works against a naive attacker provides false confidence.
Backend trust assumptions unique to mobile
Mobile backends frequently skip validation that an equivalent web API would enforce, on the assumption that "only our app" calls these endpoints. That assumption fails the moment an attacker extracts the API structure from the decompiled app — which takes minutes, not days — and begins crafting requests directly, bypassing the mobile client entirely.
A practical mobile testing checklist
A focused assessment should cover, at minimum:
- Static analysis of the compiled app for hardcoded secrets, insecure storage, and debug artifacts left in the release build.
- Dynamic analysis with traffic interception to test certificate pinning and observe real API calls the app makes.
- Session and token handling — expiry, revocation on logout, and reuse across devices.
- Server-side authorization testing against every endpoint the app calls, independent of the mobile client entirely.
- Platform-specific storage review: Keychain/Keystore usage, backup exclusion flags, and clipboard exposure of sensitive fields.
