Mobile Application Security Testing, Explained
A mobile test has three parts — the binary, the device, and the API behind them. Most of the serious risk is in the third, and the reason is that the app itself is running on hardware the attacker owns.
Mobile application testing starts from a premise that does not apply anywhere else: the application is running on hardware the attacker controls.
A web application runs on your servers. A mobile application runs on a device somebody else owns, can root or jailbreak, can attach a debugger to, and can take apart at their leisure. Any protection that depends on the app behaving itself is a speed bump, not a control.
Everything below follows from that.
The three parts
A mobile test covers the binary, the device, and the backend the app talks to. The three are usually priced together and are frequently misunderstood as one thing.
1. The binary — static analysis
The tester takes the shipped application apart without running it. For Android that means unpacking the APK or AAB and decompiling to readable code; for iOS, working with the IPA and the compiled binary.
What this reliably turns up:
- Hardcoded secrets. API keys, cloud credentials, signing keys, third-party tokens, and occasionally database connection strings compiled into the application. This is the most consistent finding in mobile testing. Anything in the binary is public — obfuscation changes how long it takes to find, not whether it can be found.
- Endpoints and infrastructure the app talks to, including staging and internal hosts left in a production build.
- Weak or homemade cryptography, hardcoded keys and initialisation vectors, and outdated algorithms.
- Debug and logging code shipped to production.
- Third-party libraries and their versions, which is how known vulnerabilities in dependencies surface.
2. The device — dynamic analysis
The tester runs the application on a rooted or jailbroken device and observes what it does.
What is written to storage. Credentials, tokens and personal data in preference files, local databases, cached responses or log files. Whether the platform's protected storage is used — Keychain on iOS, Keystore on Android — and whether the accessibility settings on those entries are appropriate.
What crosses the network. All traffic is intercepted through a proxy. Where certificate pinning is implemented, the tester bypasses it — this is expected, and it is not a failure of the pinning. Pinning is there to defeat opportunistic interception on a hostile network, not to stop someone with physical control of the device. A test that stopped at the pinning would leave the entire API untested.
What the platform exposes. On Android: exported activities, services and broadcast receivers reachable by other installed applications; content providers; deep link handling; WebView configuration. On iOS: URL scheme handling, pasteboard leakage, data captured in background snapshots, and what ends up in an unencrypted backup.
What runtime manipulation achieves. Using instrumentation to alter the application while it runs — changing what a function returns, defeating root detection, skipping a client-side check. The purpose is not to prove the app can be modified; that is a given. It is to establish what an attacker reaches by doing so, which is a question about the server.
3. The backend — where the risk usually is
Almost every mobile application is a client for an API, and that API is where the consequential findings tend to be.
The reasoning is straightforward. A flaw in the binary affects one device — the attacker's own. A flaw in the API affects every user. If client-side validation can be removed and the server accepts the result, or if changing an identifier returns another customer's data, the mobile application was merely the route in.
This is why a mobile engagement that does not include the API is incomplete, and why it is worth asking directly whether the quoted scope covers it. What that testing consists of is set out in API penetration testing.
The finding that is usually not one
Mobile reports frequently list "application runs on rooted device", "code is not obfuscated", or "certificate pinning can be bypassed" at high severity.
These are worth recording, and they are worth fixing to the extent that they raise the cost of attack. But they describe a device the attacker already owns. Treating them as top findings, ahead of an API that returns another user's records, gets the priority backwards — and a report weighted that way is worth questioning, because it suggests the test concentrated on the client and the server received less attention.
Reasonable expectations: root and jailbreak detection deters casual tampering and is defeated by anyone determined. Obfuscation increases the time to understand the binary. Pinning protects users on hostile networks. None of them substitute for the server enforcing its own rules.
What the tester needs
- The build to be tested, and agreement on which one — a release build behaves differently from a debug build, and testing the wrong one produces findings that do not apply to what users have.
- Distribution that works — TestFlight, an internal distribution channel, or the file directly. This is a recurring cause of lost days on iOS.
- Accounts at every privilege level, on at least two tenants, for the API half.
- Any device or OS version constraints, if the app supports a range.
- Notice of anti-tampering or attestation controls, so time is not spent establishing by trial and error that the app refuses to run under instrumentation.
Frameworks worth knowing by name
The OWASP Mobile Application Security Verification Standard sets out requirements at defined levels; the Mobile Application Security Testing Guide is the corresponding procedure. If a proposal names them, the work has a published structure behind it. If it names only "industry best practice", ask what that means in this instance.
Security Brigade's brand blog carries a walkthrough of the OWASP Mobile Top 10 for the vulnerability classes themselves. This piece is about how the testing is conducted; that one is about what is being looked for.
Scoping it
Two applications — Android and iOS — sharing one backend is the common case, and it is three targets, not two. The platforms are separate builds with separate platform-specific issues, and the shared API needs testing once but properly.
Quotes vary widely here, and the usual reason is that one includes the API and another does not. That is the question to ask when comparing them; the broader version of it is in comparing two empanelled vendors.
Continue reading
All articles →VAPT When No Regulator Requires It
Unregulated companies still end up buying penetration tests. The requirement arrives through customers, contracts, insurers and investors — and each wants something slightly different.
Which Indian Regulators Require Security Testing
A map rather than a manual: which regulator binds you, what instrument sets the requirement, and where to read the detail that applies to your entity type.
Writing a VAPT RFP That Gets Comparable Quotes
Most VAPT tenders return responses that cannot be compared. Four ways an RFP causes that, and what to specify instead so three proposals answer the same question.