Mobile application security testing (MAST) examines an iOS or Android app for security weaknesses using static analysis of the package, dynamic testing on a running device, and inspection of network traffic. The OWASP Mobile Application Security project supplies the standard to test against (MASVS) and the testing guide (MASTG).
What standard do you test against?
OWASP's Mobile Application Security Verification Standard, MASVS, defines what a secure mobile app should do. Its requirements are grouped into areas: storage, cryptography, authentication, network communication, platform interaction, code quality, resilience and privacy. The Mobile Application Security Testing Guide, MASTG, describes how to check each one, with techniques for both major platforms.
Using the standard turns a vague "pen test the app" into a checklist with a pass or fail for each area, which a client or auditor can review.
What are the three main techniques?
Static analysis. You take the app package, unpack it, and examine manifest and configuration files, embedded strings, third party libraries and decompiled code, without running it. This finds hard coded secrets, exported components that other apps can call, permissive backup settings and vulnerable libraries.
Dynamic analysis. You run the app on a test device or emulator and watch what it does: which files it writes, what it logs, how it handles input, and what happens to its memory and sessions. Tools can hook functions at run time to see data before encryption. This finds insecure storage and broken authentication flows.
Network analysis. You route the app's traffic through an intercepting proxy on a test device and check that all communication uses TLS with proper certificate validation, and that sensitive data does not travel in URLs or logs. This also exposes the backend API, which should be tested separately because the server is the real boundary.
A fourth area, resilience, looks at how hard the app makes it to tamper with or reverse engineer it. MASVS treats this as defense in depth, relevant to apps with high risk such as payments, and not a substitute for fixing real flaws.
What does a finding look like?
A constructed example. A banking app saves a long-lived session token in a plain preferences file on the device. Static review shows the file name in the code. Dynamic testing on a device with a debug build confirms the token is readable. The effect: anyone with access to a lost or backed-up device, or malware with file access on a compromised device, can use the session.
The fix is to store the token in the platform's secure keystore, shorten its lifetime and bind it to the device. Under MASVS, it maps to the storage area, and a retest confirms it.
When should teams test?
Automated static checks belong in the pipeline, run on every build, since they are quick and find regressions. Dynamic and manual tests are slower and suit pre-release gates and after major changes. Test the backend APIs the app calls in the same cycle, since many mobile problems are really server access control failures.
Do not forget third party code. Mobile apps embed advertising, analytics and other software development kits. Each one runs with the app's permissions, so list them and check their versions.
What are the limits?
Automated scanners produce false positives and miss logic flaws, such as a purchase flow that can be replayed. Testing on a rooted or jailbroken device is useful for analysis but does not show what a typical user's device exposes. Platform behavior changes between operating system versions, so retest after major updates.
How to check or apply this
- Choose the MASVS areas that matter for your app's risk, and write them as a checklist.
- Run automated static analysis and a dependency check on every build.
- Review the manifest for exported components, permissions and backup settings.
- Capture network traffic from a test device and confirm TLS validation and no secrets in URLs.
- Check local storage after login and logout for tokens and personal data.
- Test the backend endpoints for authorization separately.
- Keep a list of embedded third party SDKs with versions.
Quick check
Is MAST the same as a mobile penetration test?
A penetration test is one way to do MAST. MAST also includes automated checks that run continuously in a build pipeline.
Do I need to test both iOS and Android?
Yes if you ship both. The standard is common, but storage, permissions and platform features differ.
Sources
- OWASP Mobile Application Security Verification Standard
- OWASP Mobile Application Security Testing Guide
Last reviewed: 18 October 2026.
