TL;DR
- ✓Mobile app penetration testing assesses an iOS or Android app's client binary, local data storage, and the APIs it talks to, using the OWASP MASVS verification standard and the MASTG test guide.
- ✓It combines static analysis (decompiling with jadx or Hopper, inspecting the IPA/APK with MobSF) and dynamic analysis (runtime instrumentation with Frida and objection on a jailbroken or rooted device).
- ✓Core test areas are insecure data storage, weak cryptography, authentication, network security (TLS and certificate pinning), platform interaction (exported components, deeplinks), and resilience (root/jailbreak and tamper detection).
- ✓iOS and Android differ in storage (Keychain vs Keystore), packaging (IPA vs APK), and language (Swift/Objective-C vs Kotlin/Java), but the methodology and MASVS controls are shared.
- ✓A typical engagement runs 5 to 10 days per platform and produces CVSS-scored findings mapped to MASVS controls.
Roughly two thirds of the OWASP Mobile Top 10 risks live on the client device, not the server, which is exactly why a web pentest of your backend misses them. Mobile application penetration testing is the practice of attacking an iOS or Android app the way a real adversary would: pulling the binary apart, reading what it writes to disk, intercepting its traffic, and rewriting its logic at runtime.
This post explains what mobile app pentesting actually covers, how iOS and Android engagements differ, the standard (OWASP MASVS) and tools that drive the work, and what you get out of an assessment.
What is mobile app penetration testing?
Mobile app penetration testing is an authorized security assessment of a mobile application's client code, on-device data, and the backend APIs it calls. The goal is to find and exploit vulnerabilities before an attacker does, then report them with reproduction steps and risk ratings.
It is broader than a server pentest because the attacker fully controls the device. They can root or jailbreak it, decompile your app, dump memory, hook functions at runtime, and tamper with traffic. So the assessment treats the app binary itself as an untrusted, fully visible artifact. Work is graded against the OWASP Mobile Top 10 for risk categories and the OWASP MASVS for verifiable controls.
What does a mobile pentest actually test?
A mobile pentest covers seven control areas defined by OWASP MASVS, spanning the client and its data:
- Storage: secrets, tokens, and PII written to SharedPreferences, plists, SQLite, or external storage in cleartext.
- Cryptography: hardcoded keys, ECB mode, static IVs, weak hashes, and home-rolled crypto instead of Keychain/Keystore-backed material.
- Authentication and session: token handling, biometric bypass, and logout/session invalidation.
- Network: TLS configuration and certificate pinning, tested by intercepting traffic through Burp Suite or mitmproxy.
- Platform interaction: exported activities, services, content providers, deeplinks, and WebView misconfigurations.
- Code quality: injection into WebViews, debug flags, and third-party SDK risk.
- Resilience: root/jailbreak detection, anti-tampering, and anti-instrumentation, which protect higher-risk apps.
The full per-control test list lives in our mobile app penetration testing checklist.
How is iOS pentesting different from Android?
The methodology is shared, but the platform internals differ in five concrete ways. Android ships an APK (a ZIP you can unpack with apktool and decompile with jadx); iOS ships an IPA containing a Mach-O binary you disassemble with Hopper or Ghidra. Android apps run Kotlin/Java on ART; iOS runs Swift/Objective-C compiled to native code.
- Secure storage: Android uses the Keystore and SharedPreferences; iOS uses the Keychain and plists/NSUserDefaults. Misuse on either side leaks tokens.
- Privilege: Android needs root (Magisk) for deep inspection; iOS needs a jailbreak (or a re-signed debug build) to run Frida server.
- IPC: Android exposes exported components, intents, and content providers (probe them with Drozer); iOS uses URL schemes, universal links, and XPC.
- App stores: iOS code signing and FairPlay encryption mean you often work from a decrypted IPA pulled off-device.
iOS vs Android: what changes in a pentest
| Area | Android | iOS |
|---|
| Package | APK (apktool, jadx) | IPA / Mach-O (Hopper, Ghidra) |
| Language | Kotlin / Java on ART | Swift / Objective-C native |
| Secure store | Keystore, SharedPreferences | Keychain, plists |
| Privilege | Root via Magisk | Jailbreak or re-signed build |
| IPC surface | Exported components, intents, Drozer | URL schemes, universal links, XPC |
Mobile pentesting follows the OWASP MASTG methodology: static analysis first, then dynamic. Static analysis means inspecting the app without running it. You unpack the APK/IPA, decompile to readable code (jadx, apktool, Hopper, Ghidra), and run an automated triage scan with MobSF to surface obvious storage, crypto, and manifest issues.
Dynamic analysis means attacking the running app on a rooted or jailbroken device. Frida hooks and rewrites functions in memory; objection wraps Frida for one-liners like SSL pinning bypass and Keychain dumps. Burp Suite or mitmproxy sit in the network path to read and modify HTTPS traffic. Drozer probes Android IPC. When an app refuses to honor a proxy or pins its certificate, you fall back to forced redirection, which we cover in intercepting proxy-unaware app traffic. Increasingly, this static-plus-dynamic loop is automated, which is the idea behind agentic pentesting.
Strobes insight
Most exploitable mobile findings are not zero-days in the binary; they are tokens and PII sitting in cleartext on disk and a missing certificate pin. Test storage and network first.
Why does mobile pentesting matter for compliance?
It matters because mobile apps hold regulated data (health records, payment cards, PII) directly on devices you do not control, and most frameworks now expect a mobile-specific assessment rather than a generic app scan. Insecure local storage and weak transport are the findings that turn into breach notifications.
If your app handles sensitive data, the storage and crypto controls map directly to regulatory obligations. We break that mapping down in mobile pentesting for data protection compliance. Pairing a MASVS-aligned pentest with that compliance view gives auditors evidence and gives your team an actionable fix list.
Frequently asked questions
What is mobile application penetration testing?
It is an authorized security assessment of an iOS or Android app that attacks the client binary, on-device data storage, and the backend APIs it calls. Testers decompile the app, intercept its traffic, and instrument it at runtime to find vulnerabilities, then report them with CVSS scores mapped to OWASP MASVS controls.
Do you need a jailbroken or rooted device?
For thorough dynamic analysis, yes. Root on Android (via Magisk) or a jailbreak on iOS lets you run Frida server, read protected app directories, and bypass pinning. Some checks can run on non-rooted devices using re-signed debug builds or patched APKs, but resilience and storage testing are far easier with elevated access.
What is the difference between OWASP MASVS and MASTG?
MASVS (Mobile Application Security Verification Standard) defines the security requirements, the what, grouped into Storage, Crypto, Auth, Network, Platform, Code, and Resilience. MASTG (Mobile Application Security Testing Guide) is the how, providing concrete test cases and tool walkthroughs to verify each MASVS control.
How long does a mobile app pentest take?
A typical single-platform engagement runs 5 to 10 days depending on app size, the number of features, and whether resilience controls (root detection, anti-tampering) are in scope. Testing both iOS and Android roughly doubles the effort, though API and backend findings often carry over between platforms.
Is testing the backend API part of a mobile pentest?
Usually yes. A mobile app is a thin client over an API, and many high-severity findings (broken object-level authorization, mass assignment) live server-side. Mobile engagements should include the APIs the app calls, tested with Burp Suite against intercepted traffic.
What are the most common mobile app vulnerabilities found?
Insecure local data storage (tokens and PII in cleartext), missing or bypassable certificate pinning, weak or hardcoded cryptographic keys, exported components and unvalidated deeplinks, and weak root/jailbreak detection. These map to the OWASP Mobile Top 10 and recur across most apps.
Sources and references
S
Shubham Jha
Security Researcher, Strobes
Shubham Jha leads offensive security research at Strobes, focused on web and API exploitation and red team tradecraft.
