Mobile applications carry attack surface that web reviewers frequently miss. The application sits on a device that the user controls, communicates with back end services that may or may not be properly hardened, stores data locally in ways that need to survive device compromise and integrates with platform services that have their own security properties. A mobile review that focuses only on the network traffic between the device and the back end misses most of the interesting attack surface.

Local Storage Is A Real Risk

Mobile applications routinely cache sensitive data on the device for offline access or performance reasons. The caching mechanisms vary by platform, by framework and by developer decision, which means the protection applied to that cached data varies considerably. Authentication tokens stored in plaintext, personal data left in temporary files, credentials embedded in shared preferences and biometric data handled outside the secure enclave are all common findings. A focused web application pen testing engagement on a mobile application should specifically include local storage review across the supported platforms.

Certificate Pinning Is Often Misimplemented

Certificate pinning protects mobile applications from man in the middle attacks that traditional TLS does not catch. The implementation details matter. A pinning configuration that pins the wrong certificate, fails open on validation errors or includes a backdoor that disables pinning under certain conditions defeats the purpose. Many published mobile apps still ship with pinning configurations that look correct in code review and fail in practice.

Expert Commentary

William Fieldhouse, Director of Aardwolf Security Ltd

A finding we report routinely is a mobile application that does everything right at the protocol layer and stores sensitive data in plain text on the device. The team that built the app focused on the network. The team that should have reviewed device side storage either did not exist or did not have visibility into the project. Mobile security crosses team boundaries in ways that web security usually does not.

Third Party SDKs Multiply The Surface

Third party SDKs embedded in mobile applications can carry their own vulnerabilities, telemetry that the application owner did not request and integration patterns that bypass the application security model. Review every SDK before adoption, keep them updated and monitor for vulnerability disclosures. A vulnerable SDK in a popular application can affect millions of users without the application developers being aware. Worth maintaining an inventory of the SDKs embedded in each application along with their versions and known issues. The inventory is straightforward to maintain and provides the starting point for any response to a newly disclosed SDK vulnerability.

Reverse Engineering Resistance Has Limits

Code obfuscation, anti-tampering measures and root or jailbreak detection all increase the cost of attack but none of them make a mobile application unbreakable. Treat them as time-buying controls rather than permanent defences. Pair them with a regular vulnerability scan services approach that includes mobile applications in its scope. The combination of operational discipline and structured testing produces meaningful results.

Mobile applications run on devices you do not control. Plan the security model accordingly. Mobile applications carry attack surface that desktop reviewers often miss. Worth scoping the testing accordingly. Mobile security is its own discipline and rewards specialist attention. The teams that treat mobile applications as a distinct domain rather than a web application variant tend to produce more secure applications and avoid the embarrassing findings that mobile-specific reviews reliably surface.