Key Takeaways
- OWASP MASVS (Mobile Application Security Verification Standard) is the framework for mobile app security testing. The companion MASTG (Mobile Application Security Testing Guide) provides specific test cases.
- Mobile pentest covers three layers: binary analysis (APK/IPA), runtime behaviour (Frida, Objection), backend API touchpoints.
- Top findings in Indian mobile app pentests: insecure data storage, weak certificate pinning, missing root/jailbreak detection, hardcoded API keys, insecure deeplink handling.
- Modern threats: biometric bypass on Android/iOS, third-party SDK supply chain risk, dynamic feature delivery abuse, app clone detection bypass.
- Indian SaaS / fintech / banking apps typically need OWASP MASVS Level 2 compliance for customer due diligence and regulatory scrutiny.
Why Mobile App Pentest Is Different From Web App Pentest
Mobile applications run on user-controlled devices. This is the fundamental difference from web applications, where the server controls execution. On a mobile device, a determined attacker has root or jailbreak access, can decompile the binary, modify execution at runtime, and intercept all traffic. Mobile app security assumes the device is hostile.
Mobile pentest covers three layers: binary analysis (static analysis of APK/IPA, examining manifests, resources, embedded keys, native libraries, obfuscation), runtime analysis (dynamic analysis using Frida, Objection, Burp Suite proxy, intercepting calls, modifying app behaviour), backend API analysis (the API endpoints the mobile app calls, which carry the actual data and authorisation logic).
OWASP recognises mobile-specific concerns with a dedicated framework: OWASP MASVS (Mobile Application Security Verification Standard) defines security requirements; OWASP MASTG (Mobile Application Security Testing Guide) defines test cases. Together they are the international reference for mobile pentest methodology.
OWASP MASVS Verification Levels
MASVS defines three verification levels based on the security threat model of the application:
MASVS-L1: Standard Security
Generic mobile application security suitable for most consumer apps. Covers basic platform interaction, data storage, cryptography, authentication, network communication, code quality, anti-tampering basics. Appropriate for: most consumer-facing mobile apps, content apps, productivity apps, low-sensitivity B2B apps. Most Indian SaaS apps should achieve L1 at minimum.
MASVS-L2: Defence-in-Depth
L1 plus advanced controls for apps handling sensitive data or operating in hostile environments. Covers: certificate pinning, advanced data-at-rest encryption, anti-tampering, anti-debugging, runtime application self-protection (RASP), biometric authentication best practices. Appropriate for: fintech apps, banking apps, payment apps, health apps with PHI, identity apps, enterprise apps handling sensitive corporate data.
MASVS-R: Resilience Against Reverse Engineering
Optional resilience requirements adding obfuscation, anti-tampering checks, runtime integrity validation. Appropriate for: high-value targets (DRM, payment processing, copyright protection, gambling, gaming with high-value virtual goods). Typically combined with L2 not as standalone.
Need a Pentest Engagement?
Codesecure runs manual + AI-augmented VAPT for Indian businesses: web, API, mobile, network, cloud, AD, IoT, source code. Named OSCP/CEH/CISSP consultants, ISO/IEC 27001:2022 certified delivery, free retest within 90 days.
See Pentest Services →Mobile Pentest Methodology: Practical Steps
Phase 1: Reconnaissance and Static Analysis
Download the APK or IPA. Decompile using jadx (Android), Hopper or Ghidra (iOS). Examine: AndroidManifest.xml or Info.plist for permissions and exported components, embedded resources for hardcoded secrets, native libraries (.so files for Android, dylib for iOS) for additional logic, obfuscation status (ProGuard, R8, LLVM obfuscation), debug flags. Tools: jadx, apktool, MobSF, Frida-Trace, otool, class-dump.
Phase 2: Runtime Analysis Setup
Rooted Android emulator or jailbroken iOS device. Install the target app. Set up runtime instrumentation: Frida server on device, Objection for high-level instrumentation, Burp Suite or Mitmproxy with installed CA certificate for traffic interception. Bypass any anti-emulator or anti-jailbreak detection if needed using Frida hooks (this is part of MASVS-R testing).
Phase 3: Data Storage Testing
Inspect what data the app stores on device and how: SharedPreferences (Android) or NSUserDefaults (iOS) for plaintext sensitive data, SQLite databases for unencrypted PII, external storage for sensitive files, keychain or Android Keystore usage. Test: launch app, perform sensitive operations (login, payment), inspect device storage, look for credentials, tokens, PII in plaintext. Frequent finding in Indian apps: API tokens stored in SharedPreferences without encryption.
Phase 4: Network Communication Testing
Intercept TLS traffic via Burp/Mitmproxy. Test: certificate pinning bypass (Frida hooks to bypass app-level pinning), TLS configuration (versions, ciphers), API endpoints called, request and response payload analysis, authentication mechanism. Identify: hardcoded backend URLs (production vs staging), API keys in headers, JWT structure, MFA implementation. Combine with backend API pentest for full coverage.
Phase 5: Authentication and Session Testing
Test: login flow including credential storage, OAuth/SSO integration, biometric authentication bypass (Android: BiometricPrompt hooks; iOS: LAContext bypass), session token storage and lifecycle, automatic logout, account recovery flows, MFA enforcement, deep link authentication bypass. Frequent finding: biometric authentication bypassed by Frida hooking the callback, allowing access without actual biometric match.
Phase 6: Platform Interaction Testing
Android: exported activities, services, content providers, broadcast receivers, deep link handling, intent injection, WebView misuse (loadData, JavaScript bridges with sensitive permissions). iOS: URL scheme handling, universal links, WKWebView configuration, IPC via XPC, keyboard extensions. Test: malicious app on same device sending crafted intents/URLs to target app, observe if sensitive functions are accessible without proper authorisation.
Phase 7: Backend API Testing
Mobile app is just one client of the backend API. Run full API pentest aligned to OWASP API Top 10 against the backend the mobile app uses. Combine with mobile findings to surface end-to-end attack chains: e.g., mobile-stored token + weak API authorisation = full account takeover.
Modern Mobile Threats Beyond OWASP MASVS
Biometric Authentication Bypass
Android BiometricPrompt and iOS LAContext can be bypassed via Frida hooks on rooted/jailbroken devices unless the app uses proper key-bound authentication (CryptoObject on Android, LAPolicy.deviceOwnerAuthenticationWithBiometrics with key access on iOS). Test: hook the authentication callback, force a 'success' result, observe if app grants access without actual biometric. Mitigation: bind biometric to key access, not just to UI callback.
Third-Party SDK Supply Chain Risk
Mobile apps include 10-50+ third-party SDKs (analytics, push notifications, payment, advertising, crash reporting). Each SDK has its own security posture. Compromised or malicious SDKs are a real attack vector. Test: inventory third-party SDKs, check known-malicious lists, verify SDK versions are current, identify SDKs with excessive permissions. Indian mobile apps frequently bundle outdated versions of analytics SDKs with known vulnerabilities.
Dynamic Feature Delivery Abuse
Android App Bundle and iOS On-Demand Resources allow downloading features after install. If the dynamic feature integrity is not verified, attacker can substitute malicious modules. Test: examine dynamic feature loading, verify cryptographic verification, check whether dynamic modules can access sensitive APIs.
WebView and Hybrid App Risks
Hybrid frameworks (React Native, Flutter, Ionic, Capacitor) bridge native and web layers via WebViews and JavaScript bridges. Test: WebView configuration (JavaScript enabled with sensitive bridge access), URL loading without validation, file:// access in WebView, JavaScript bridge methods exposing sensitive native capabilities to web content.
Frequently Asked Questions
Should our mobile app target MASVS Level 1 or Level 2?
Consumer-facing apps with low data sensitivity: L1. Fintech, banking, payment, healthcare, identity, enterprise B2B with sensitive corporate data: L2. Apps with high-value virtual goods, DRM, copyright protection or critical infrastructure access: L2 + MASVS-R. Most Indian B2C SaaS apps land at L1; fintech/healthcare/banking at L2. Codesecure scopes pentest to the MASVS level you target.
Do we need to test both Android and iOS or just one?
Both if you release both. Even with shared code (React Native, Flutter), platform-specific runtime, storage and IPC differ. A vulnerability fixed in Android may persist in iOS due to different keychain semantics or biometric API differences. Codesecure mobile pentest pricing: INR 1.5L-2.5L per platform separately, INR 2.5L-4L for both platforms with shared backend API included.
Is testing on a rooted/jailbroken device acceptable?
Yes, that is the standard mobile pentest setup. We assume the device is rooted/jailbroken because: (a) real attackers have rooted devices, (b) testing on a clean device hides issues that are easily exploitable on a compromised device. Apps with strong anti-root/anti-jailbreak detection still need testing on rooted devices with Frida bypassing the detection, because the detection itself can fail in production.
What about React Native and Flutter apps?
Both fully supported. React Native: examine JavaScript bundle in the APK/IPA, identify embedded keys and business logic, analyse native modules. Flutter: examine compiled Dart in app binary, runtime analysis through Frida (more complex than native because of Flutter's runtime). Hybrid frameworks add complexity but also reduce some attack surface compared to native (less custom security implementation).
How do we test biometric authentication for our mobile app?
Three-layer test: (1) is the biometric callback properly bound to a key in the secure element (Android Keystore with setUserAuthenticationRequired, iOS SecAccessControl with biometric), or merely a UI callback the app trusts? (2) is the success result tied to a cryptographic operation, not just a boolean flag the runtime can flip? (3) on bypass, does the app still verify the unlocked key against a server-side challenge? Apps that fail (1) and (2) are bypassed by Frida hooks in seconds.
Will the mobile pentest report satisfy auditors and app store reviewers?
Codesecure mobile pentest reports map findings to OWASP MASVS controls, MASTG test cases, CWE, CVSS v3.1, MITRE ATT&CK Mobile. Acceptable to SOC 2 auditors as evidence of mobile-app security testing, to ISO 27001 auditors under A.8.29 (security testing), to Apple App Store and Google Play Store reviewers as supporting evidence for security claims. Indian fintech app submissions to RBI and SEBI also accept the reports.
How long does mobile app pentest take?
Typical timeline: single-platform Android or iOS pentest 1-2 weeks, both platforms with shared backend 2-3 weeks, complex fintech/healthcare apps with extensive features 3-4 weeks. Plus 1 week for report finalisation, plus free retest within 90 days when fixes are ready.
Get a Mobile App Pentest Aligned to OWASP MASVS
Codesecure runs Android and iOS pentests aligned to OWASP MASVS L1/L2 and MASTG test cases. Binary analysis, runtime testing with Frida, backend API testing. Named OSCP/CEH consultants, ISO/IEC 27001:2022 certified, free retest within 90 days.
