Mobile App Penetration Testing with OWASP MASVS

Mobile applications present a distinct and often underestimated attack surface. Unlike web applications running entirely on servers you control, mobile apps execute on devices owned by users — devices that may be rooted or jailbroken, connected to untrusted networks, and subject to static and dynamic analysis by sophisticated attackers. The OWASP Mobile Application Security Verification Standard (MASVS), now in its v2 form, provides the most comprehensive framework for mobile application security testing and verification.

Understanding OWASP MASVS v2 structure

MASVS v2 reorganises mobile security controls into five categories. MASVS-STORAGE governs sensitive data storage on the device and in backups. MASVS-CRYPTO covers the use of cryptographic primitives and key management. MASVS-AUTH addresses authentication and authorisation at the application layer. MASVS-NETWORK covers secure communication between the app and backend services. MASVS-PLATFORM governs the app's interaction with the mobile OS and other applications. MASVS-CODE covers software quality, anti-tampering, and anti-reverse-engineering controls (particularly relevant for banking and financial applications).

The companion Mobile Application Security Testing Guide (MASTG) provides the specific test cases and techniques for each MASVS control — it is the practitioner's reference that translates the verification standard into actionable tests.

Static analysis: what we look for in the binary

Static analysis (SAST) of mobile applications begins with decompiling or disassembling the application binary. For Android, tools decompile APK files to recover Java/Kotlin source code and examine the AndroidManifest.xml for dangerous permissions, exported components, and debug flags left in production builds. For iOS, analysis of the IPA binary reveals Objective-C class dumps, Swift symbols, and Mach-O binary properties.

Common static findings include: hardcoded credentials, API keys, and authentication tokens embedded in the binary (CWE-798); sensitive data written to device logs in production builds; backup-enabled flags on components containing sensitive data; exported Activities or Services that can be invoked by other applications without authorisation; missing certificate pinning implementation; and debug flags or developer backdoors left active in release builds. In BFSI applications, the presence of hardcoded API keys or authentication tokens in a banking app binary is a critical finding with significant regulatory implications.

Dynamic analysis: runtime behaviour testing

Dynamic analysis tests the application's behaviour at runtime. Testing is conducted on both physical devices and emulators, on rooted/jailbroken devices where anti-tampering controls need to be bypassed for thorough assessment. Key dynamic tests include: intercepting and manipulating HTTPS traffic using a proxy (Burp Suite or equivalent) after installing a custom CA certificate; testing for SSL pinning bypass (if the application implements certificate pinning, assess whether it can be bypassed using tools like Frida or objection); testing sensitive data storage — where does the application store data locally, is it accessible to other applications, and is it present in device backups?; and testing authentication session management — token storage location, token expiry, and the application's behaviour after logout.

Anti-tampering and reverse engineering controls

For banking, payments, and other sensitive financial applications, MASVS-CODE controls around anti-tampering and obfuscation are not optional. RBI guidelines for mobile banking applications expect controls that detect rooted/jailbroken devices, detect code tampering, and implement binary obfuscation to raise the cost of reverse engineering. Testing these controls requires actively attempting to bypass them using dynamic instrumentation frameworks — if a tester can trivially bypass root detection and tamper with transaction values, a real attacker can too.

Network security: beyond basic TLS

Mobile applications must implement network security correctly at multiple levels. TLS configuration should enforce TLS 1.2 or higher with a secure cipher suite, reject self-signed certificates, and — for sensitive applications — implement certificate pinning with a robust pinning strategy that supports certificate rotation without app updates. Many applications implement pinning but leave it trivially bypassable, providing false assurance.

Test for cleartext traffic permissions in AndroidManifest.xml. Test whether the application leaks sensitive data in URL parameters, HTTP headers, or request bodies that are accessible in transport logs. If the application uses third-party SDKs (analytics, crash reporting, advertising), assess whether those SDKs receive or transmit sensitive data without adequate controls.

CyVigilant's mobile app VAPT service covers both Android and iOS using the OWASP MASVS/MASTG methodology. For banking and fintech apps, our testing aligns with RBI mobile banking security guidelines. Talk to an expert to scope your mobile security assessment.