What is mobile app penetration testing?

A mobile app penetration test is an authorised, time-boxed attack on a mobile application, performed by a security professional, to find what a real attacker could achieve. The application can be a consumer iOS app, an Android app, a cross-platform app, or an enterprise mobile app.

The scope usually covers three layers at once:

• The client (the app binary). What is stored inside it, what it does at runtime, what protections it ships with, and whether those protections can be undone.
• The data. What the app stores on the device, what it transmits, and whether sensitive data is exposed at rest or in transit.
• The backend API. The endpoints the app talks to. In practice this is where most of the high-impact findings are. See mobile API testing.

One structural difference changes everything: in mobile, the attacker holds the client.

In a web application, the server controls the page and the attacker only sees what the server sends. In a mobile application, the attacker installs the app on a device they fully control. From there they can:

• Decompile the binary and read the code, embedded secrets, API keys, and logic.
• Run the app on a rooted or jailbroken device where every security boundary is theirs to remove.
• Hook into the running app with instrumentation tooling and change its behaviour live: skip a check, change a value, dump memory. See Frida.
• Intercept the app's network traffic even when the app tries to prevent it. See certificate pinning bypass.

The practical consequence: any security control the app tries to enforce on the device is a speed bump, not a wall. The real security boundary is the backend. A mobile pentest that only checks the app and ignores the API misses where the damage is.

The recurring high-impact findings from real engagements:

• Hardcoded secrets in the binary. API keys, credentials, encryption keys, and third-party tokens embedded in the app and trivially extracted by decompiling it.
• Insecure local storage. Sensitive data (tokens, personal information, cached responses) stored unencrypted on the device.
• Weak or bypassable transport security. Traffic that can be intercepted because pinning is absent or bypassable.
• Backend authorisation flaws. The API trusts the app to enforce rules the attacker can ignore. This is where the BOLA / IDOR class shows up in mobile.
• Client-side trust. The app enforces a business rule (a price, a limit, a permission) on the device, and the backend does not re-check it.
• Bypassable protections. Root / jailbreak detection, certificate pinning, and anti-tamper that the tester defeats to demonstrate the protection is not a real boundary.

Two OWASP standards define the bar:

• OWASP MASVS (Mobile Application Security Verification Standard). The checklist of what a secure mobile app should do, organised into categories like storage, cryptography, authentication, network, and resilience.
• OWASP MASTG (Mobile Application Security Testing Guide). The how-to manual that shows the techniques for verifying each MASVS requirement.

A good engagement maps findings to MASVS so the customer can see exactly which requirements pass, which fail, and what to fix. Compliance frameworks (PCI MPoC, app-store requirements, enterprise procurement) increasingly reference MASVS directly.

Four phases.

Phase 1, static analysis. Decompile the binary, read the code, hunt for embedded secrets, map the data the app stores, review the protections it ships with.

Phase 2, dynamic analysis. Run the app on an instrumented device. Observe and modify it at runtime. Test local storage, inter-process communication, deep links, and the protections (pinning, root detection) by attempting to bypass each.

Phase 3, network and API. Intercept the app's traffic, map every endpoint, and run a full API penetration test against the backend: authentication, authorisation (BOLA), input validation, rate limiting.

Phase 4, reporting. Findings mapped to OWASP MASVS, each with reproducible evidence and the specific code, configuration, or architectural change required, plus a free re-test of fixes.

The deliverable names which MASVS requirements pass and fail, so the customer and any auditor can see the coverage.