Mobile security testing has a de facto standard: OWASP MAS. The project gives you MASVS — eight control groups defining what a secure mobile app looks like — and MASTG, the testing guide that turns each control into concrete static and dynamic test cases for Android and iOS. Used together, they convert mobile app security from ad-hoc annual pentests into a repeatable program with defined coverage: you know which controls you test, which you don't, and what evidence backs each claim.
What is OWASP MAS, and how do MASVS and MASTG relate?
OWASP MAS (Mobile Application Security) is the umbrella project with three artifacts. MASVS — the Mobile Application Security Verification Standard — is the requirements catalog: short, numbered control statements like "the app securely stores sensitive data." MASTG — the Mobile Application Security Testing Guide, formerly known as MSTG — is the how: per-platform techniques, tool walkthroughs, and test cases that verify each MASVS control on real binaries. The MAS Checklist ties the two together into a tracking sheet auditors and internal teams use to record coverage. The 2023 MASVS 2.0 restructure simplified the catalog into eight control groups and moved verification depth into testing profiles, which makes scoping conversations considerably less painful than under the old scheme.
What do the eight MASVS control groups cover?
Each group names a failure domain that shows up constantly in real mobile assessments:
- MASVS-STORAGE — sensitive data at rest: keychain/keystore usage, no secrets in shared preferences, logs, or backups.
- MASVS-CRYPTO — no home-grown ciphers, no hardcoded keys, current primitives and modes.
- MASVS-AUTH — authentication and session handling, including biometric implementation done through platform APIs rather than a boolean check.
- MASVS-NETWORK — TLS everywhere, correct certificate validation, pinning where the threat model warrants it.
- MASVS-PLATFORM — safe use of IPC, WebViews, deep links, and platform permissions — the group where inter-app attack surface lives.
- MASVS-CODE — dependency currency, platform security flags, and basic anti-exploitation hygiene in the build.
- MASVS-RESILIENCE — resistance to reverse engineering and tampering: root/jailbreak detection, obfuscation, integrity checks.
- MASVS-PRIVACY — data minimization and user consent, increasingly what app-store reviewers and regulators ask about first.
Reading an assessment scoped "MASVS-STORAGE plus MASVS-NETWORK, L1 profile" tells you precisely what was and wasn't examined — which is the entire point of testing against a standard.
How do you run mobile security testing in practice?
Static work comes first because it is cheap and parallelizable: decompile the release artifact (apktool and jadx on Android; class-dump and otool-style tooling against iOS binaries), review the manifest and entitlements for exported components and over-broad permissions, and sweep the binary for embedded secrets and stale libraries. Scanners like MobSF automate a useful fraction of this per build.
Dynamic work verifies behavior: instrument the running app with Frida to bypass certificate pinning and observe what actually crosses the wire, proxy the traffic, and inspect the filesystem on a rooted or jailbroken test device to see what the app really persisted — which is routinely different from what the code review suggested. MASTG gives you the per-platform recipes for each of these steps, so two testers produce comparable evidence.
One boundary worth drawing early: the mobile binary is half the system. The APIs behind it carry the authorization logic, injection surface, and data exposure, and they are tested with standard web techniques — SAST and DAST tooling covers that half continuously, while MASTG covers the client half.
Which MAS profile should your app target?
MAS-L1 is the baseline every app should meet — it maps to standard security practice with no exotic requirements. MAS-L2 adds defense-in-depth for apps handling sensitive data: banking, health, anything where a device compromise has regulatory consequences. The resilience profile (the controls in MASVS-RESILIENCE) layers on reverse-engineering resistance for apps whose threat model includes tampering and repackaging — mobile games with economies, apps embedding proprietary models, financial clients targeted by overlay malware.
An honest note on resilience: root detection and obfuscation raise attacker cost; none of it stops a determined analyst with a debugger and time. Budget resilience controls as friction, never as the control that protects the data — that job belongs to STORAGE, CRYPTO, and the backend.
How does mobile security testing fit into CI/CD?
Split by cadence. Every build: automated static checks — manifest lint, secret sweep, dependency scan, MobSF or equivalent — gating on the same new-findings-only principle as any other pipeline gate. Every release candidate: a scripted dynamic pass over the highest-risk MASTG cases for your profile — pinning, storage, auth flows — on real devices. Annually or per major release: a human-led assessment against the full MAS Checklist, because instrumentation-heavy testing and business-logic abuse still need people. Teams building internal capability for that middle tier can work through the Safeguard Academy materials on mobile testing technique; the tooling half without the skills half plateaus quickly.
FAQ
What is the difference between MASVS and MASTG?
MASVS states requirements — what must be true of the app. MASTG supplies test cases — how to verify each requirement on Android and iOS binaries. You scope an engagement with MASVS and execute it with MASTG.
Do you need jailbroken or rooted devices for mobile security testing?
For meaningful dynamic testing, yes — filesystem inspection, runtime instrumentation, and pinning bypass all want an unlocked device or a well-configured emulator. Purely static work and API testing do not, which is why they make up the automated tier.
Is mobile security testing different from API security testing?
Complementary halves. Mobile testing examines the client: storage, platform integration, resilience, what leaves the device. API testing examines the server: authorization, injection, rate limiting. A program that tests only the binary misses where the data lives; one that tests only the API misses what the device leaks.
How often should a mobile app be tested?
Automated static checks on every build, a scripted dynamic pass on every release candidate, and a full human-led MAS assessment annually or after major architectural change — new auth flow, new payment path, new SDK with deep platform access.