A Developer’s Guide to Securing Mobile Apps with OWASP MASVS

Mobile app security best practices are easiest to apply when they are tied to a standard your testers, auditors and developers all share. For mobile, that standard is the OWASP Mobile Application Security Verification Standard (MASVS).

This guide walks through each MASVS control group with concrete implementation advice for Android and iOS: where to store secrets, how to pin certificates without bricking your app, when runtime protection (RASP) is worth it, and how to protect the APIs behind the app.

It includes configuration snippets, a server-side attestation flow and a release checklist.

Why mobile apps need their own security standard

A mobile app runs on a device you do not control. Users install it on rooted phones, attackers decompile it, and malware on the same device can watch the screen or overlay fake UI.

Server-side controls still matter most, but the client needs its own hardening.

Real incidents show the cost of getting basics wrong. Symantec found more than 1,800 Android and iOS apps leaking hardcoded AWS credentials, and a 2026 study of 444 AI-enabled iOS apps found roughly two-thirds exposed usable AI service keys in network traffic.

On the device side, banking trojans now use overlay screens to steal PINs and card details.

The OWASP Mobile Top 10 2024 list names the risks: M1 Improper Credential Usage, M2 Inadequate Supply Chain Security, M3 Insecure Authentication/Authorization, M4 Insufficient Input/Output Validation, M5 Insecure Communication, M6 Inadequate Privacy Controls, M7 Insufficient Binary Protections, M8 Security Misconfiguration, M9 Insecure Data Storage and M10 Insufficient Cryptography.

MASVS gives you the controls to address them.

OWASP MASVS at a glance

OWASP MASVS organizes requirements into eight control groups. The companion Mobile Application Security Testing Guide (MASTG) explains how to test each one.

MASVS group	Focus	Related Mobile Top 10 risk
MASVS-STORAGE	Protecting sensitive data at rest	M9
MASVS-CRYPTO	Correct use of cryptography and key management	M10
MASVS-AUTH	Authentication and authorization	M1, M3
MASVS-NETWORK	Secure network communication	M5
MASVS-PLATFORM	Safe interaction with the OS and other apps	M4, M8
MASVS-CODE	Code quality, dependencies, input handling	M2, M4
MASVS-RESILIENCE	Resistance to reverse engineering and tampering	M7
MASVS-PRIVACY	Data minimization and user control	M6

Every app should meet the core groups. RESILIENCE controls are a risk decision: they matter most for apps that handle money, valuable accounts, licensed content or competitive play.

Storage and cryptography (MASVS-STORAGE, MASVS-CRYPTO)

Keep secrets out of the binary

Anything shipped in the app package can be extracted. Do not embed cloud keys, admin tokens or third-party API secrets. Symantec’s follow-up research found hardcoded AWS and Azure credentials in popular apps with millions of downloads.

Instead, have the backend broker access, issuing short-lived, narrowly scoped tokens to authenticated users.

Use the platform keystores

• Android: generate keys in Android Keystore (hardware-backed or StrongBox where available) and use them to encrypt local data. Never store tokens in plain SharedPreferences.
• iOS: store tokens in the Keychain with an accessibility class such as kSecAttrAccessibleWhenUnlockedThisDeviceOnly so they do not migrate in backups.
• Exclude sensitive files from cloud backups, and avoid writing personal data or tokens to logs, caches, screenshots or the clipboard.

Do not invent cryptography

Use platform or well-reviewed libraries, authenticated encryption (AES-GCM) and random IVs. Hardcoded keys or IVs defeat encryption entirely.

Network security and certificate pinning (MASVS-NETWORK)

All traffic should use TLS 1.2 or later with platform defaults. On Android, disable cleartext traffic; on iOS, keep App Transport Security on without broad exceptions.

When and how to use certificate pinning

Certificate pinning makes the app trust only specific public keys for your API, which blocks interception through a user-installed or rogue CA.

It does not stop a determined attacker on a rooted device who can hook the TLS stack, so treat it as one layer. Pin the public key (SPKI hash) of your own intermediate or leaf, always include a backup pin, and set an expiry so a forgotten pin cannot lock users out.

<!– Android: res/xml/network_security_config.xml (illustrative) –>
<network-security-config>
  <base-config cleartextTrafficPermitted=”false” />
  <domain-config>
    <domain includeSubdomains=”true”>api.example.com</domain>
    <pin-set expiration=”2027-06-30″>
      <pin digest=”SHA-256″>PRIMARY_SPKI_HASH_BASE64=</pin>
      <pin digest=”SHA-256″>BACKUP_SPKI_HASH_BASE64=</pin>
    </pin-set>
  </domain-config>
</network-security-config>

Plan key rotation before you ship: generate the backup key in advance, publish app updates that include the new pin, then rotate the server certificate.

Authentication and API security (MASVS-AUTH)

The app is just one client of your API, and attackers will call the API directly. Every authorization decision must be enforced on the server.

Practical rules

• Use OAuth 2.0 with PKCE via the system browser (ASWebAuthenticationSession, Custom Tabs) rather than embedded web views for login.
• Issue short-lived access tokens and rotate refresh tokens; bind them to the device where possible and revoke on logout or suspicious activity.
• Check object-level authorization on every request. Changing an account ID in a request must never return another user’s data.
• Offer passkeys or biometric unlock backed by a keystore key, not a biometric check that simply flips a local boolean.
• Rate-limit login, OTP, password reset and high-value endpoints per user, device and IP.

APIs need continuous attention after launch. Teams should monitor and protect these APIs constantly, watching for scraping, enumeration and automated abuse patterns that the app itself would never generate.

Resilience, RASP and app attestation (MASVS-RESILIENCE)

Resilience controls raise the cost of reversing and tampering. Dynamic instrumentation toolkits such as Frida, covered in our report on the Frida 16.7.0 release, are standard tools for testers and attackers alike, so assume your client logic can be inspected and modified.

Runtime application self-protection

RASP lets the app monitor itself for suspicious behavior while it runs: root or jailbreak, hooking frameworks, debuggers, emulators, repackaging and overlay or accessibility abuse.

Report these signals to the backend rather than only crashing locally, so the server can decide whether to allow a payment, withdrawal or ranked match.

Server-verified attestation

Google’s Play Integrity API tells your backend whether a request came from your genuine app binary on a genuine Android device, and Apple’s App Attest (DCAppAttestService) provides the equivalent on iOS.

The key design point is that the verdict is checked on your server.

1. Client requests a one-time nonce from the backend before a sensitive action.
2. Client obtains an integrity token or assertion that includes the nonce.
3. Backend verifies the token with Google or validates the Apple assertion, checks the nonce and app identity, and applies policy.
4. Policy decides: allow, require step-up, limit features or deny.

This matters because malware increasingly targets app integrity directly. ThreatFabric reported a 2026 trojan that tries to replace legitimate banking apps with malicious copies, which attestation of the genuine binary is designed to expose.

Practitioner example: hardening an app with in-app value

Illustrative scenario. A team ships a mobile game with an in-app currency wallet and real-money purchases.

A pre-release review against MASVS finds a payment provider secret in the APK, session tokens in plain preferences, no pinning, and purchase validation done on the client.

Finding	MASVS group	Fix
Provider secret in APK	STORAGE / AUTH	Move to backend; rotate the secret immediately
Tokens in plain preferences	STORAGE	Encrypt with Keystore-held key; shorten token lifetime
Client-side purchase validation	AUTH / CODE	Verify store receipts server-side before crediting the wallet
No pinning, cleartext allowed	NETWORK	Disable cleartext; add SPKI pins with a backup and expiry
No tamper detection	RESILIENCE	Add attestation on purchase and withdrawal; RASP signals to backend

The same pattern applies to any app holding value, from fintech wallets to real-money gaming platforms such as the Aviator sites that attract automated abuse: server-side truth, short-lived credentials and attested clients.

Release checklist for mobile app security best practices

1. No secrets in the binary (scan with a secrets scanner in CI).
2. Sensitive data encrypted with platform keystores and excluded from backups.
3. TLS only, no cleartext, pins with backup and expiry where pinning is used.
4. All authorization enforced on the server; object-level checks tested.
5. Dependencies and SDKs inventoried and scanned (Mobile Top 10 M2).
6. Attestation checked server-side for sensitive actions; RASP signals logged.
7. Privacy review: data minimization and permissions justified (MASVS-PRIVACY).
8. MASTG-based test pass before each major release.

For governance, map this work to NIST CSF 2.0 (Protect: data security and platform security) and CIS Controls v8 Control 16 (application software security).

Key takeaways

• Mobile app security best practices are easiest to adopt when mapped to OWASP MASVS control groups.
• Never ship secrets in the app; use platform keystores and short-lived server-issued tokens.
• Certificate pinning helps against interception but needs backup pins, expiry and a rotation plan.
• Enforce all authorization on the server and protect APIs against direct, automated abuse.
• Use RASP and Play Integrity or App Attest, and always verify attestation on the backend.

FAQ

What is OWASP MASVS?

The OWASP Mobile Application Security Verification Standard is a set of security requirements for iOS and Android apps, grouped into storage, crypto, auth, network, platform, code, resilience and privacy controls.

Is certificate pinning still recommended for mobile apps?

It is useful for apps handling sensitive data, as long as you pin public keys, include a backup pin, set an expiry and plan rotation. It complements, but does not replace, server-side controls.

What is RASP in mobile app security?

Runtime application self-protection is code inside the app that detects tampering, hooking, debugging, rooting or emulators while it runs, and reports or responds to those conditions.

How do I store API keys securely in a mobile app?

Do not store long-lived secrets in the app. Have the backend issue short-lived, scoped tokens to authenticated users, and keep any device-held keys in Android Keystore or the iOS Keychain.

What is the difference between Play Integrity and App Attest?

Both let a backend confirm requests come from a genuine copy of your app. Play Integrity covers Android apps distributed through Google Play; App Attest is Apple’s equivalent for iOS.