Mobile App Security: OWASP Standards and Release Checklist 2026

Updated October 2026 by the Cliffex team.

Mobile app security means protecting the data on the device, the connection to your servers, the backend APIs and the app code itself. The most widely used reference points are the OWASP Mobile Top 10, which lists the most common mobile risks, and the OWASP Mobile Application Security Verification Standard (MASVS), which defines the security requirements an app should meet. This guide explains both and turns them into a practical checklist for secure mobile app development and release.

Mobile app security standards: OWASP Mobile Top 10 and MASVS

The OWASP Mobile Top 10 is an awareness list. The current edition is the 2024 final release, which replaced the 2016 list (OWASP):

Risk	What it means in practice
M1: Improper Credential Usage	Hardcoded API keys or passwords, or credentials stored and sent insecurely
M2: Inadequate Supply Chain Security	Vulnerable or malicious third-party SDKs and libraries, or a compromised build pipeline
M3: Insecure Authentication/Authorization	Weak login, sessions that never expire, permission checks done only in the app
M4: Insufficient Input/Output Validation	Injection and unsafe handling of data from users, deep links or APIs
M5: Insecure Communication	Cleartext traffic, weak TLS settings, accepting invalid certificates
M6: Inadequate Privacy Controls	Collecting, logging or sharing more personal data than needed
M7: Insufficient Binary Protections	Apps that are easy to reverse engineer or modify
M8: Security Misconfiguration	Debug flags left on, exported components, over-broad permissions
M9: Insecure Data Storage	Sensitive data in plain files, preferences, logs or backups
M10: Insufficient Cryptography	Weak algorithms, hardcoded keys, home-made encryption

The OWASP MASVS is the requirements standard. OWASP describes it as the industry standard for mobile app security, for use by architects and developers building apps and by testers checking them. It groups controls into eight areas: STORAGE, CRYPTO, AUTH, NETWORK, PLATFORM, CODE, RESILIENCE and PRIVACY. Its companions are the Mobile Application Security Testing Guide (MASTG), a manual for testing those controls on Android and iOS, and the MASWE, a list of mobile-specific weaknesses.

Not every app needs every control. The MAS testing profiles help you choose:

• MAS-L1: the baseline recommended for all apps, and on its own for apps handling low-risk data.
• MAS-L2: for apps that handle high-risk sensitive data or functions, such as health apps (OWASP).
• MAS-R: resilience against reverse engineering and tampering, for apps that need to protect their own logic or content, such as games and apps with license checks (OWASP).
• MAS-P: a privacy baseline for apps that deal with sensitive user data.

When a client, regulator or enterprise buyer asks for “mobile app security requirements”, agreeing on a MASVS profile is a clear way to define scope for both development and testing.

Secure data storage on the device

The safest data is data the app never stores. When it must store tokens, keys or personal data, use the platform’s protected storage. On iOS that is Keychain Services. On Android, the Android Keystore keeps cryptographic keys non-exportable and can require user authentication before a key is used. Encrypt sensitive local databases with keys held there, and check that secrets do not leak into logs, screenshots, the clipboard, crash reports or cloud backups.

Authentication and authorization

• Use proven identity flows. For OAuth sign-in, RFC 8252 says native apps should send authorization requests through an external user agent (normally the system browser), and public native clients must use PKCE.
• Keep sessions short. Use short-lived access tokens with refresh tokens stored in the Keychain or Keystore, and revoke them on logout or password change.
• Add biometrics properly. Face ID or fingerprint should unlock a key held in secure hardware. A biometric check that only returns true or false in app code is easy to bypass.
• Authorize on the server. Hiding a button in the app is not access control. Every API call must check that this user may perform this action on this record.

API and network security

The backend API holds most of the data an app shows, so it deserves as much attention as the app. The OWASP API Security Top 10 (2023) puts Broken Object Level Authorization first: APIs that accept an object ID from the user without checking whether that user may access it. Validate every input on the server, apply rate limits, return only the fields the app needs, and never ship server secrets inside the app, because anything in the binary can be extracted.

For transport, use HTTPS everywhere. Android’s Network Security Configuration lets you opt out of cleartext traffic, restrict trusted certificate authorities and pin certificates, and iOS enforces secure connections through App Transport Security. Certificate pinning adds protection for high-risk apps, but it needs a rotation plan so a certificate change does not break every installed copy.

To check that requests come from your real app, use platform attestation: Google’s Play Integrity API helps verify that requests come from your genuine app on a genuine Android device, and Apple’s App Attest lets your server confirm requests come from legitimate instances of your iOS app. The decision to trust or block happens on your server.

Mobile app code protection

Any app installed on a phone can be downloaded, decompiled and modified. Code protection raises the effort required; it cannot make extraction impossible. That is why secrets and business rules that matter belong on the server.

• Obfuscation. On Android, R8 shrinks code and shortens class, field and method names when you enable it for release builds. Flutter has an –obfuscate build option, and React Native release builds that use the Hermes engine ship pre-compiled bytecode. iOS apps compile to native code, and commercial tools can add further obfuscation where the risk justifies it.
• Tamper and environment checks. Detect rooted or jailbroken devices, debuggers, hooking frameworks and repackaged builds, and report the result to the server through attestation.
• Signing key protection. Store release signing keys securely. Google’s Play App Signing keeps the app signing key with Google, and the upload key can be reset if lost.

These measures map to the MASVS-RESILIENCE controls and the MAS-R profile. Banking, gaming, media and apps with paid features usually need them. A simple internal tool may not.

Mobile app release security checklist

Many vulnerabilities enter at release time, through debug settings or new dependencies. Before each store submission we check:

• Debug flags are off (for example android:debuggable), test endpoints and verbose logging are removed, and no secrets are in the bundle.
• Third-party SDKs and libraries are reviewed and scanned for known vulnerabilities, addressing OWASP’s M2 supply chain risk.
• Exported Android components, URL schemes and deep links accept only what they should.
• Permissions are the minimum needed, and the App Store privacy details and Google Play Data safety form match what the app does.
• Obfuscation is enabled and mapping files are stored privately for crash reporting.
• Automated static and dependency scans run in the CI pipeline, and higher-risk releases get manual testing against the agreed MASVS profile using the MASTG.
• A plan exists to push security fixes quickly, including a forced-update mechanism for critical issues.

Security testing

Combine automated and manual testing. Static analysis (SAST) and dependency scanning catch common mistakes on every build. Dynamic testing on real devices, with traffic interception and runtime inspection, finds problems in storage, network and authentication. For apps with high-risk data, an independent penetration test against the MASTG before launch and after major changes gives the strongest assurance. Organizations vetting apps for their own staff can also refer to NIST’s guidance, SP 800-163 Rev. 1.

Compliance and regulated apps

Health, finance and payment apps carry legal requirements such as HIPAA, PCI DSS or GDPR. Following the MASVS supports these, but it does not by itself make an app compliant. Compliance depends on your policies, agreements and hosting. We build the technical safeguards to the requirements you and your compliance advisers set.

Cost of building a secure mobile app

Security work is part of every Cliffex build, and its scope grows with the MASVS profile you need. Apps that handle sensitive data or need MAS-L2 or MAS-R controls usually fall in our Business app ($10,000–$20,000, 6–12 weeks) or Advanced platform ($20,000+, 12–16+ weeks) tiers. Independent penetration testing is typically a separate cost. Every project includes 30 days of post-launch support, then hourly maintenance at $25–$49/hr on an approved estimate, which covers dependency updates and security fixes. See pricing and our app cost guide.

How Cliffex can help

We build iOS, Android and cross-platform apps with secure storage, server-side authorization and release checks planned from the start. Our healthcare SaaS platform and document scanning app for accounting firms both handle sensitive data. See our mobile app development services or ask us to review your app.

Frequently asked questions

What are the main mobile app security standards?

The OWASP MASVS defines the requirements, the OWASP MASTG explains how to test them, and the OWASP Mobile Top 10 (2024) lists the most common risks. NIST SP 800-163 Rev. 1 covers app vetting for organizations.

What is secure mobile app development?

It means building security into each stage: threat modeling and requirements, secure storage and authentication in code, a hardened API, automated scans in CI, and testing before every release.

How do you protect mobile app code from reverse engineering?

Enable obfuscation (R8 on Android, Flutter’s obfuscate option), add tamper and root or jailbreak detection, use Play Integrity or App Attest, and keep secrets and important logic on the server.

What should I check before releasing a mobile app?

Debug settings off, no secrets in the bundle, dependencies scanned, minimal permissions, accurate privacy disclosures, obfuscation on, and testing against your chosen MASVS profile.