Mobile application penetration testing is not web-app testing with a different client. The attack surface, tooling, and methodology are distinct enough that organizations that lump them together routinely get superficial findings on both. This is the practitioner’s guide to mobile application penetration testing for Android and iOS in 2026, mapped to OWASP MASVS L2 with notes on what separates credible engagements from brochure-level testing.
The two platforms — what makes them different
Android and iOS look similar from the user’s perspective and are radically different from the tester’s:
- Android is more open. APK is unpacked easily; Java/Kotlin code decompiles to readable output; runtime instrumentation (Frida, Xposed) works on most builds; network proxying is straightforward. More attack surface to audit; more vectors available to attackers.
- iOS is more constrained. IPA requires jailbroken device or Corellium-style virtualization for full runtime access; Objective-C and Swift reverse engineering is harder though tooling has matured; many instrumentation frameworks are more limited. Less attack surface; more friction for attackers and testers alike.
A credible mobile test covers both platforms independently, with testers who have platform-specific expertise.
The methodology — OWASP MASVS L2
The OWASP Mobile Application Security Verification Standard defines two levels. L1 is baseline; L2 is defense-in-depth for apps handling sensitive data. Indian SaaS and fintech mobile apps should target L2.
MASVS-L2 covers 8 control groups:
- MASVS-STORAGE — secure handling of data at rest
- MASVS-CRYPTO — appropriate use of cryptography
- MASVS-AUTH — authentication and authorization mechanisms
- MASVS-NETWORK — network communication security
- MASVS-PLATFORM — platform interaction (permissions, inter-app communication, system features)
- MASVS-CODE — code quality and build configuration
- MASVS-RESILIENCE — resistance to reverse engineering and tampering (L2-specific)
- MASVS-PRIVACY — privacy-preserving practices
Android testing — what we actually do
Static analysis
- APK unpacking with
apktool; JAR extraction withdex2jar; Java decompilation withjadx,JD-GUI, orBytecode Viewer - Manifest review: exported components, permissions, intent filters, backup settings, debuggable flag, networkSecurityConfig
- Hardcoded secrets — API keys, OAuth secrets, URLs pointing to internal infrastructure
- Native library review for C/C++ code (JNI); if security-critical, disassembly with Ghidra or IDA
- Third-party library inventory with MobSF or manual analysis against known-vulnerable-version databases
Dynamic analysis
- Network proxying through Burp Suite or Caido (requires root for HTTPS; or patched APK for non-root devices)
- Certificate pinning bypass with Frida scripts if the app enforces pinning
- Runtime instrumentation — modifying app behavior at runtime with Frida or Objection
- Storage inspection — SharedPreferences, SQLite databases, external storage, internal files
- Inter-process communication testing — exported activities, broadcast receivers, content providers, services
- Deep-link handling — malformed URLs, scheme hijacking, parameter injection
Common Android findings
- Cleartext traffic allowed (missing
cleartextTrafficPermitted="false") - Backup-enabled app with sensitive data (should be
allowBackup="false") - Debuggable flag enabled in release build
- Exported activities with insufficient permission checks
- Hardcoded secrets in DEX or resources
- Weak or missing certificate pinning
- Sensitive data in SharedPreferences without encryption
- SQLite databases with sensitive data, unencrypted
- Log statements emitting PII
iOS testing
Static analysis
- IPA extraction; class-dump for Objective-C class structure; Ghidra/Hopper for disassembly
- Info.plist review: URL schemes, ATS settings, permissions, application categories
- Embedded strings analysis for secrets, internal URLs, debug flags
- Binary protection analysis: PIE, ARC, stack canaries, NX
Dynamic analysis
- Requires jailbroken device (checkra1n, palera1n) or Corellium virtualization
- Network proxying with configured trust store or Burp CA on device
- Frida for iOS, Objection, or manual Cycript for runtime inspection
- Keychain inspection for credential storage
- Filesystem access to app container for stored data analysis
- IPC testing — URL schemes, Universal Links, custom interfaces
Common iOS findings
- ATS exceptions permitting non-TLS connections
- Keychain accessible without user authentication requirement
- URL scheme handlers without validation
- Sensitive data in NSUserDefaults without encryption
- Jailbreak detection too weak to resist standard bypass
- Debug symbols in production binary
- Hardcoded secrets in binary strings
Backend API testing
Mobile apps are clients of backend APIs. Every mobile penetration test must include thorough testing of the APIs the app consumes — this is frequently where the most severe findings live. See our separate guide on API security testing.
Platform-specific security features to verify
Android
- Network Security Configuration explicitly set; no default-trust-user-certificates in production
- App transport security via
usesCleartextTraffic="false" - SafetyNet/Play Integrity API attestation for sensitive operations
- Biometric authentication via BiometricPrompt, not legacy FingerprintManager
- Android Keystore for cryptographic key storage, with user-authentication-required flag for sensitive keys
iOS
- App Transport Security enforced; exceptions only where absolutely required
- DeviceCheck or App Attest API for device and app integrity
- LocalAuthentication framework with appropriate policy for biometric access
- Keychain items configured with appropriate
accessibleattribute (nokSecAttrAccessibleAlwaysfor sensitive data) - Secure Enclave for cryptographic operations on sensitive keys
Typical engagement shape
A credible mobile pen test for one production app (Android + iOS):
- 10–15 tester-days (more for complex apps, less for simple ones)
- Grey-box — tester has working credentials, test-tenant access, build artifacts
- Full MASVS L2 coverage, plus backend API coverage
- Findings report with reproduction steps, evidence (video or screenshot), remediation guidance at code level
- Typical cost range: ₹1,25,000–₹2,50,000
Related reading
- VAPT Services in India: The Complete Buyer’s Guide
- API Security Testing: OWASP API Top 10 in Practice
- Web Application Penetration Testing Checklist
For a mobile application penetration test scoped to your Android/iOS app, book a scoping call.