Mobile security: OWASP MASVS for iOS and Android

What is MASVS

The Mobile Application Security Verification Standard (MASVS) is OWASP's reference for mobile application security. It defines security requirements organized into verifiable categories. The MASTG (Mobile Application Security Testing Guide) provides the concrete tests for each requirement. Together, they form the foundation of any serious mobile security audit.

The verification categories

MASVS-STORAGE: data storage

Everything the application stores locally on the device. Files, SQLite databases, SharedPreferences (Android) or UserDefaults (iOS), the Keychain, and caches. The central question: is sensitive data stored in plaintext in accessible locations?

Common issues: authentication tokens in SharedPreferences without encryption, personal data in unencrypted SQLite files, credentials in application logs.

MASVS-CRYPTO: cryptography

Does the application use robust and current encryption algorithms? Are keys properly generated, stored, and rotated? Common problems include the use of DES or RC4, hardcoded keys in source code, and no key rotation.

MASVS-AUTH: authentication and session management

Identity verification must not rely solely on the mobile client. Biometric authentication should be coupled with a server-side mechanism. Sessions must expire server-side, not only client-side. A token stored on the device without server-side expiration allows permanent access even after revocation.

MASVS-NETWORK: network communication

All communications must use TLS 1.2 minimum. Certificate pinning protects against man-in-the-middle attacks even if a certificate authority is compromised. But beware: poorly implemented pinning can make the application unusable during certificate renewal.

MASVS-PLATFORM: platform interaction

How the application interacts with the operating system. IPC (Inter-Process Communication), deep links, requested permissions, WebViews. A poorly validated deep link can let a malicious application trigger actions in your app. A WebView with JavaScript enabled and local file access is a major attack vector.

MASVS-CODE: code quality and resilience

Is the application protected against reverse engineering? Is obfuscation applied? Are anti-tampering mechanisms present? In practice, any mobile application can be decompiled. The question is how much time and effort it takes.

iOS vs Android differences

Android: the permission model has been more granular since Android 6.0. Applications are signed but not verified through a process as strict as the App Store. Internal storage (/data/data/[package]) is isolated but accessible on a rooted device. SharedPreferences are unencrypted XML by default.

iOS: the Keychain provides native secure storage but must be configured correctly (with the right accessibility level). Data in NSUserDefaults is not encrypted. App Transport Security (ATS) enforces TLS by default but developers often add exceptions.

Verification levels

MASVS defines two levels:

Health and finance applications should target L2 at minimum. As auditors, CleanIssue checks L1 requirements systematically and L2 for applications handling sensitive data.

Request your audit call to evaluate your mobile application against the MASVS framework.