Mobile App Penetration Testing (Android & iOS)

Web application testing assumes the server is trusted and the client is not. Mobile testing takes that further: the entire application ships to the adversary. A user can root or jailbreak their device, decompile the app, read its storage, and intercept its traffic. Anything the app "knows" — keys, logic, endpoints — is knowable to whoever holds the phone. The OWASP Mobile Application Security Verification Standard (MASVS) organises this problem into verifiable requirements, and a good engagement works methodically down the stack it describes.

The client and the binary

Everything starts with the app package — an APK on Android or an IPA on iOS. Because it lives on the attacker's device, it can be reverse engineered. Android bytecode decompiles cleanly back to near-readable Java or Kotlin; iOS binaries can be disassembled and their Objective-C or Swift metadata inspected. The first questions a tester asks are: what secrets are embedded here, what logic runs client-side that should run on the server, and how does the app behave on a rooted or jailbroken device?

Root and jailbreak detection

Many apps try to detect a compromised device and refuse to run. This is a reasonable defence-in-depth measure, but it is not a security boundary — the check runs inside the very binary the attacker controls, and can be patched out or hooked at runtime with instrumentation frameworks. A finding here is rarely "detection was bypassed" (it always can be); it is "the app relied on that detection to protect something it should have protected server-side."

Insecure local storage

The most common and most damaging class of mobile finding is sensitive data written to insecure local storage. Session tokens, personal data, and even credentials end up in shared preferences, property lists, SQLite databases, log files, or cached web content — often in plaintext. Both platforms provide a hardware-backed secure store for secrets: the iOS Keychain and the Android Keystore. The test is straightforward and revealing: exercise the app, then inspect its sandbox and see what it left behind.

A related trap is unintended data leakage: sensitive values landing in system logs, in analytics payloads, in keyboard caches, or in the app-switcher screenshot the OS takes when the app backgrounds. None of these are exotic exploits — they are hygiene failures that a device forensics pass surfaces immediately.

Weak transport security

Traffic between the app and its backend must be protected in transit, and testing this means placing an intercepting proxy between the two. A well-built app uses TLS everywhere and adds certificate pinning — validating that the server presents an expected certificate rather than merely any certificate a trusted authority signed. Pinning defeats a casual man-in-the-middle attempt that installs a proxy's root certificate on the device.

Certificate pinning is a speed bump, not a wall. On a device you control you can usually bypass it — so the real question is whether the API behind it stands on its own.

A tester who bypasses pinning to observe the API is not demonstrating a flaw in pinning; they are removing an obstacle so they can assess the backend. The genuine transport findings are the opposite: cleartext HTTP endpoints, TLS that accepts weak ciphers or invalid certificates, and mixed content where a secure app quietly loads an insecure resource.

The backend is where impact lives

Once past transport, the app is just an HTTP client, and the API it talks to is the real prize. Every server-side weakness familiar from web testing applies — broken object-level authorisation, injection, mass assignment, business-logic flaws — with a mobile twist: developers sometimes assume the app is the only client and enforce rules in the UI rather than on the server. A tester replaying and modifying requests directly, ignoring the app entirely, routinely finds that a value the app never lets you change is happily accepted by the API.

Authorisation, not authentication

The most valuable backend findings are authorisation flaws: can user A retrieve user B's records by changing an identifier? Can a normal account invoke an admin-only endpoint the app hides? Because the mobile client can be made to send anything, server-side authorisation is the only control that actually holds. This is why the layered model matters — the three layers on the device are all bypassable, so the backend must assume it is talking to a hostile client.

Binary protections and their limits

Obfuscation, anti-debugging, and anti-tampering raise the cost of reverse engineering, and they have a place — particularly for apps handling payments or high-value content. But they are cost, not prevention. The correct posture is to treat every client-side protection as delay, keep no secret in the binary that would be catastrophic to disclose, and put every enforceable control on the server. An app designed this way remains secure even when a determined attacker fully understands it.

Running the engagement

A structured mobile test combines static analysis of the decompiled package, dynamic analysis with the app running on an instrumented device, and backend testing of the API surface. The MASVS and its companion testing guide give a repeatable checklist so coverage is provable rather than anecdotal, and so a report can state not just what was found but what was verified.