Mobile Application Security with OWASP MASVS in Practice

Mobile applications have become the primary interface between organizations and their customers. They handle sensitive personal data, process financial transactions, and often serve as authentication factors for other services.

Yet mobile security testing frequently receives less attention than web application testing. The assumption that app store review processes catch security issues, combined with the perception that mobile platforms are inherently more secure, leads to dangerous gaps.

Here's what you need to know about mobile application security, based on our experience conducting security assessments against OWASP MASVS.

Why Mobile Security Differs from Web Security

While mobile and web applications share some security concerns, several factors make mobile security unique:

Local Data Storage

Web applications typically store minimal data client-side. Mobile apps often cache significant amounts of data locally, including authentication tokens, personal information, and business data. This local storage becomes a target for attackers with physical or malware-based access to devices.

Platform-Specific Considerations

iOS and Android have different security models, different storage mechanisms, and different vulnerabilities. Security testing must address platform-specific concerns, not just application logic.

Network Trust

Mobile apps often operate on untrusted networks: public WiFi, compromised cellular networks, or networks with malicious actors performing man-in-the-middle attacks. Proper certificate validation and traffic security are critical.

Reverse Engineering

Unlike web applications where server-side code is protected, mobile application binaries are distributed to users. Determined attackers can reverse engineer the application, understand its logic, and identify vulnerabilities that wouldn't be apparent through external testing alone.

Interprocess Communication

Mobile platforms allow applications to communicate with each other through various mechanisms. Improperly secured communication channels can allow malicious apps to interact with your application in unintended ways.

OWASP MASVS Explained

The OWASP Mobile Application Security Verification Standard (MASVS) provides a framework for assessing mobile security. It defines three verification levels:

MASVS-L1: Standard Security

Appropriate for all mobile applications. Addresses common vulnerabilities that every app should prevent.

Key requirements:

• Proper authentication and session management
• Secure network communication
• Basic data protection
• Resistance to common tampering techniques

MASVS-L2: Defense-in-Depth

For applications handling sensitive data (financial, healthcare, personal). Adds additional controls even when the device is compromised.

Additional requirements:

• Advanced data protection even on compromised devices
• Additional authentication factors
• Code hardening against reverse engineering
• Detection of modified runtime environments

MASVS-R: Resilience Against Reverse Engineering

For applications with high-value assets or strict IP protection requirements. Focuses on preventing reverse engineering and tampering.

Additional requirements:

• Anti-debugging techniques
• Device integrity verification
• Code obfuscation
• Tamper detection mechanisms

Common Vulnerabilities We Find

Based on hundreds of mobile application assessments, these issues appear repeatedly:

1. Insecure Data Storage

What we find:

• Sensitive data stored in plaintext on the device
• Credentials saved in SharedPreferences (Android) or UserDefaults (iOS) without encryption
• Sensitive information written to application logs
• Cache files containing authentication tokens or personal data

Example finding: Application stores user's session token in a plaintext file accessible to any application on a rooted/jailbroken device. Combined with token reuse vulnerability, this allows permanent account compromise.

Fix: Use platform-provided secure storage (Keychain on iOS, Keystore on Android). Never log sensitive information. Clear caches of sensitive data when the app closes.

2. Improper Certificate Validation

What we find:

• Applications that accept any certificate
• Certificate pinning implementations with bypass vulnerabilities
• Mixed content issues (some traffic encrypted, some not)
• Failure to validate certificate chain

Example finding: Application implements certificate pinning but falls back to system trust store on failure, allowing trivial man-in-the-middle attacks by adding a CA to the device.

Fix: Implement certificate pinning correctly without fallback. Test pinning implementation on actual intercepted traffic, not just unit tests.

3. Weak Authentication

What we find:

• Biometric authentication without server-side verification
• Bypassable local authentication checks
• Weak password policies
• Session tokens that never expire

Example finding: Application uses fingerprint authentication, but the verification happens entirely client-side. Patching the application binary to skip the fingerprint check grants full access without credentials.

Fix: Biometric authentication should unlock a cryptographic key that enables server-side verification, not just bypass a client-side check.

4. Hardcoded Secrets

What we find:

• API keys embedded in application binaries
• Encryption keys hardcoded in source
• Backend credentials stored in configuration files
• Third-party service credentials in client code

Example finding: Application contains hardcoded AWS access keys with broad permissions. Keys are easily extracted from the binary and provide access to backend infrastructure.

Fix: Never embed secrets in mobile applications. Use proper backend authentication flows where the server holds secrets.

5. Insecure Interprocess Communication

What we find:

• Exported activities/services without proper authentication (Android)
• Overly permissive URL scheme handlers (iOS)
• Intent injection vulnerabilities (Android)
• Lack of input validation in IPC handlers

Example finding: Android application exports a service that performs privileged operations without caller verification. A malicious app can invoke this service to perform actions on behalf of the user.

Fix: Minimize exported components. Validate callers before performing sensitive operations. Use signature-level permissions for inter-app communication.

Secure Development Patterns

Beyond fixing individual vulnerabilities, these patterns should guide mobile development:

Data Minimization

Only collect and store data that's absolutely necessary. Data that doesn't exist can't be stolen.

// Bad: Store everything "just in case"
UserProfile.save(
  fullName, email, phone, address,
  socialSecurityNumber, birthDate,
  creditCardNumber, ...
)

// Better: Store only what's needed for app functionality
UserProfile.save(fullName, email)
// Fetch sensitive data on-demand, don't cache

Secure Defaults

Make the secure option the easy option. If developers have to go out of their way to be secure, security won't happen consistently.

// Good: HTTP client configured securely by default
let secureClient = SecureHTTPClient() // Pinning enabled, proper TLS

// Bad: Requires developer to remember to configure security
let client = HTTPClient()
client.enableCertPinning()  // Easy to forget

Fail Securely

When security checks fail, the application should deny access, not grant it.

// Bad: Grant access on error
if (!verifyBiometric()) {
  if (error.type == UNAVAILABLE) {
    // Just let them in...
    proceedToApp()
  }
}

// Good: Deny access on any failure
if (!verifyBiometric()) {
  showAuthenticationRequired()
  return
}

Defense in Depth

Don't rely on a single security control. Layer defenses so that compromise of one layer doesn't mean complete compromise.

Example layers for authentication:

1. Biometric verification
2. Encrypted token in secure storage
3. Server-side session validation
4. Anomaly detection for unusual access patterns

Testing Methodology

Effective mobile security testing combines multiple approaches:

Static Analysis

Review the application binary and source code (if available) for:

• Hardcoded secrets
• Insecure API usage
• Configuration issues
• Third-party library vulnerabilities

Tools: MobSF, semgrep, proprietary static analysis

Dynamic Analysis

Test the running application for:

• Runtime behavior
• Network traffic security
• Authentication flow vulnerabilities
• Data storage issues

Tools: Frida, Burp Suite, platform developer tools

Reverse Engineering

Analyze the application binary to:

• Understand application logic
• Identify hidden functionality
• Extract hardcoded values
• Understand cryptographic implementations

Tools: jadx (Android), Hopper/IDA (iOS), Ghidra

Device Analysis

Examine what the application leaves on the device:

• File system artifacts
• Database contents
• Log files
• Cache and temporary files

Approach: Install app, use all features, examine device storage

Building Security into Mobile Development

Secure mobile applications don't happen by accident. Build security into your development process:

Threat Modeling

Before development begins, understand:

• What sensitive data will the app handle?
• What are the likely attack scenarios?
• What's the risk if the app is compromised?
• What verification level (L1/L2/R) is appropriate?

Secure Coding Training

Mobile developers need specific training on:

• Platform security mechanisms (Keychain, Keystore)
• Common mobile vulnerabilities
• Secure cryptographic implementation
• Network security configuration

Security Testing in CI/CD

Automate security checks as part of your build process:

• Static analysis on every commit
• Dependency vulnerability scanning
• Configuration security checks
• Pre-release penetration testing

Third-Party Assessment

Before major releases, get an external security assessment. Internal developers are too close to the code to see all vulnerabilities.

Next Steps

If you're responsible for mobile application security:

1. Know your apps: Inventory all mobile applications and the sensitive data they handle.

2. Assess current state: Conduct a baseline security assessment against MASVS-L2.

3. Fix critical issues: Address any findings that could lead to data exposure or account compromise.

4. Build security in: Update development processes to prevent vulnerabilities from being introduced.

5. Test regularly: Establish ongoing security testing as part of your release cycle.

Mobile applications are critical attack surfaces that deserve the same security rigor as your web applications and network infrastructure.