Mobile App Security Testing Checklist for iOS and Android (OWASP MASVS)

A mobile app security testing checklist should cover the eight areas of the OWASP Mobile Application Security Verification Standard (MASVS): data storage, cryptography, authentication and authorisation, network communication, platform interaction, code quality, resilience and privacy. It should also cover the backend API the app talks to. Use this mobile app security checklist to review each release, and have the app independently tested at least once a year and after significant change.

Mobile apps combine three things that each need testing: code running on a device you do not control, data stored on that device, and the APIs behind the app. The checklist below covers all three, with practical notes for iOS and Android.

Key takeaways

• Treat the app, the device and the backend API as one system; many serious flaws sit in the API.
• Assume the device is hostile: anything stored or bundled in the app can be extracted.
• Use the OWASP MASVS as your checklist and the OWASP testing guide (MASTG) as your method.
• Automated tools help in the build pipeline, but manual testing finds the flaws that matter.
• Test iOS and Android separately; their storage and platform controls differ.

What does the OWASP MASVS cover?

The full control text is on the OWASP MASVS site. OWASP stopped publishing its MAS checklist spreadsheet with MASTG v2.0.0, announced in July 2026, so our spreadsheet version of the checklist below maps each check to the closest MASVS control instead.

What should you agree before testing?

• Platforms and versions: iOS, Android or both, and the minimum OS versions supported.
• Build type: a test build without certificate pinning or anti-tamper controls speeds up testing; a production build shows how those controls perform.
• Backend APIs: which endpoints are in scope, and in which environment.
• Test accounts: at least two users per role, so testers can check whether one user can reach another’s data.
• Third-party SDKs: analytics, advertising, payments and authentication libraries.
• Sensitive functions: payments, identity verification, health data, account recovery.

The mobile app security testing checklist

Work through each area for iOS and Android separately. To record results, download the checklist as a spreadsheet (CSV): every check is mapped to its closest MASVS v2 control, with iOS and Android notes and columns for result and evidence.

1. Data storage (MASVS-STORAGE)

• Sensitive data is not written to plain-text files, shared preferences, local databases or logs.
• Credentials and tokens are stored only in the Keychain (iOS) or Keystore-backed storage (Android).
• Sensitive data does not leak into backups, app-switcher screenshots, the clipboard or keyboard caches.
• Data is removed from the device when the user logs out or deletes the account.

2. Cryptography (MASVS-CRYPTO)

• Only strong, current algorithms and modes are used, through platform libraries rather than home-made code.
• No encryption keys, API secrets or passwords are hard-coded in the app.
• Keys are generated and stored securely, using hardware-backed storage where available.
• Security-relevant random numbers come from a cryptographically secure source.

3. Authentication and authorisation (MASVS-AUTH)

• Authentication decisions are made on the server, not only in the app.
• Session tokens expire, can be revoked, and are invalidated on logout and password change.
• Biometric login is tied to a securely stored credential, not a simple true or false check in the app.
• Every API endpoint checks the caller is allowed to access the specific object requested.
• Sensitive actions, such as changing contact or payment details, require re-authentication.

4. Network communication (MASVS-NETWORK)

• All traffic uses TLS, with no fallback to plain HTTP.
• Certificate validation is not disabled or weakened, including in third-party libraries.
• Certificate pinning is used where the risk justifies it, and fails safely.
• iOS App Transport Security and Android Network Security Configuration allow no insecure exceptions without good reason.

5. Platform interaction (MASVS-PLATFORM)

• The app requests only the permissions it needs.
• Exported Android components are protected or not exported.
• Deep links and custom URL schemes validate input and cannot trigger sensitive actions without authentication.
• WebViews do not expose JavaScript interfaces or load untrusted content unnecessarily.
• Sensitive screens are protected from screenshots and screen recording where appropriate.

6. Code quality and supply chain (MASVS-CODE)

• Third-party libraries and SDKs are inventoried, up to date and free of known vulnerabilities.
• All input from the network, other apps, files and deep links is validated.
• The app enforces a minimum supported OS version and can prompt users to update.
• Debug features and verbose logging are removed from production builds.

7. Resilience (MASVS-RESILIENCE)

Resilience controls make an attacker’s job harder; they do not replace the controls above. They matter most for banking, payments and other high-risk apps.

• The app detects rooted or jailbroken devices, debuggers and instrumentation, and responds appropriately.
• Code obfuscation makes reverse engineering harder.
• The app detects tampering and repackaging.

8. Privacy (MASVS-PRIVACY)

• The app collects only the personal data it needs, and says clearly what it collects.
• Third-party SDKs do not collect data beyond what you have disclosed.
• Users can delete their account and data.
• Tracking identifiers are minimised and respect platform privacy controls.

How do iOS and Android differ for testing?

That is why a test of both platforms is scoped as two pieces of work, even when the apps share a backend.

What about the backend API?

Many of the most serious mobile findings are not on the device at all. They are in the API behind the app: missing authorisation checks, excessive data in responses, weak rate limiting and business logic flaws. Scope the backend into your mobile test, or test it separately with API penetration testing services. Our guide what is API penetration testing includes an API security checklist to use alongside this one.

Is mobile app security testing the same as a mobile penetration test?

Not quite. Mobile app security testing often means automated static and dynamic analysis in the build pipeline. It catches hard-coded secrets, insecure configuration, vulnerable libraries and missing platform protections on every release.

It cannot tell whether user A can read user B’s records, whether a payment flow can be manipulated, or whether a biometric check can be bypassed at runtime. Those need a tester working with the app on real devices. That is what mobile application penetration testing adds, and where source code is available, a source code review gives the deepest coverage.

What do PCI DSS, UK GDPR and ISO 27001 expect?

• PCI DSS. If your app accepts card payments, parts of it may be in scope for PCI DSS v4.0.1. Most apps use a payment provider’s SDK so card data goes straight to the provider, which keeps scope small, but secure development (Requirement 6) and testing (Requirement 11) still matter. Merchants accepting card payments on phones or tablets should also look at the PCI SSC’s Mobile Payments on COTS (MPoC) standard. A QSA can confirm your scope as part of a PCI DSS assessment.
• UK GDPR. Article 25 requires data protection by design and by default, and Article 32 requires regular testing of security measures. Mobile test results are direct evidence.
• ISO/IEC 27001:2022. Annex A controls 8.29 (security testing in development and acceptance) and 8.8 (technical vulnerabilities) both apply.

What should happen after testing?

Fix findings in order of risk, starting with anything that exposes other users’ data or allows account takeover. Retest to confirm the fixes, and feed recurring issues back into developer training and pipeline checks. Our guide to penetration test remediation covers prioritising and retesting.

Why Sovereign Secure

Sovereign Secure is a PCI SSC Qualified Security Assessor (QSA) company, an IASME-licensed Cyber Essentials certification body and ISO 27001 certified. Our mobile testing follows the OWASP MASVS and MASTG, covers the API behind the app, and includes a retest.

Next step

Tell us the platforms, the number of user roles and whether the API is in scope. Our penetration testing quote form turns that into a fixed price for testing your iOS app, Android app or both.