TL;DR: The OWASP Mobile Application Security Verification Standard (MASVS) lists the security properties a mobile app should have, grouped into areas: storage, cryptography, authentication and authorisation, network communication, platform interaction, code quality, resilience against reverse engineering and tampering, and privacy (version 2.1.0, checked November 2026). The Mobile Application Security Testing Guide (MASTG) explains how to test each property on Android and iOS, statically and dynamically. Use them to scope an assessment: start from what the app protects and who attacks it, pick the MASVS controls those threats touch, test those with MASTG techniques, and include resilience controls only where the threat model justifies them.
How to approach it
Say what each document is (requirements versus test methods), name the control areas, then show how you would turn them into a scoped, prioritised test plan for a specific app. Interviewers want to hear that you will not test everything equally.
A strong answer
Storage
Sensitive data at rest
Crypto
Correct algorithms and keys
Auth
Server-side authentication and authorisation
Network
TLS, validation, pinning where justified
Platform
IPC, WebViews, user interface
Code
Dependencies, input handling, updates
Resilience
Anti-tamper and anti-RE, when the threat model needs it
Privacy
Data minimisation and transparency
MASVS: what "secure" means for an app. Its control groups (each prefixed MASVS-):
| Group | Asks, roughly |
|---|---|
| STORAGE | Is sensitive data stored securely and kept out of logs, backups and shared places? |
| CRYPTO | Are strong primitives used correctly, with keys managed through platform facilities? |
| AUTH | Are authentication and authorisation enforced by the backend, with local auth used correctly? |
| NETWORK | Is traffic protected with correctly validated TLS, and is pinning used where the threat calls for it? |
| PLATFORM | Are IPC, WebViews, deep links and UI interactions (overlays, screenshots) handled safely? |
| CODE | Are dependencies current, inputs validated, and platform features used safely? |
| RESILIENCE | Does the app resist and detect tampering, debugging and reverse engineering where needed? |
| PRIVACY | Does the app minimise data collection and give users transparency and control? |
Version 2 dropped the old verification levels L1/L2/R in favour of controls plus "profiles" chosen by risk, which matches how it should be used anyway.
MASTG: how to check. For each control, MASTG describes techniques and tests on each platform: where to look for sensitive data on disk, how to review keystore and keychain use, how to intercept traffic and verify certificate validation, how to enumerate exported components and deep links, how to assess anti-tamper controls with instrumentation in an authorised test, and so on. It is the method library; MASVS is the requirement list.
Scoping an assessment. Example: a retail bank's app that shows balances, moves money and stores a refresh token.
- Assets and threats: account takeover, fraudulent transfers, data exposure on lost devices, malware on the device, network interception, cloned apps.
- Map to controls: STORAGE (token storage and backups), AUTH (server-side authorisation of transfers, session handling, biometric unlock design), NETWORK (TLS validation, pinning decision), PLATFORM (deep links that start payments, WebViews, overlay protection on the transfer screen), CODE (third-party SDKs and their data collection), RESILIENCE (a profile appropriate for banking: root detection and attestation as risk signals), PRIVACY.
- Prioritise by impact: transfer authorisation and token handling first; resilience controls are tested for what they signal to the server, not as a pass or fail on their own.
- Include the backend: most severe mobile findings are API authorisation bugs discovered through the app. MASVS-AUTH explicitly points at the server.
Reporting. Tie each finding to the MASVS control it violates, give preconditions (rooted device, physical access, network position) and real impact, and state which controls were out of scope or untestable.
What interviewers probe next
- "Would you require RESILIENCE controls for every app?" No. A banking or DRM app may justify them; a notes app gains little and pays in complexity. Choose by threat model.
- "How do you test an app without the source?" Static analysis of the package (manifest, decompiled code), dynamic testing on a test device with instrumentation and traffic interception, plus API testing against the backend.
- "What does MASVS not cover?" Backend security in depth, organisational processes and business-logic flaws specific to your product; it is a baseline, not a complete threat model.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
A mobile team asks how OWASP MASVS should shape their security work for a new payments app.
Start here
What is OWASP MASVS, and what does it cover?
What areas does it cover?
The OWASP Mobile Application Security Verification Standard lists the security properties a mobile app should have, grouped into areas: storage, cryptography, authentication and authorisation, network communication, platform interaction, code quality, resilience and privacy.
Carry it forwardMASVS defines mobile security properties.
Weak answerTreating it as a test script.
Constraint changes
How does MASTG relate?
Where are the test procedures?
The Mobile Application Security Testing Guide describes how to test each property, with techniques for Android and iOS. MASVS says what; MASTG says how to verify.
Carry it forwardMASVS for requirements, MASTG for testing.
Weak answerUsing MASVS without MASTG.
Constraint changes
How should the team use it during design?
Which requirements apply to payments?
Pick the requirements relevant to a payments app, turn them into user stories and acceptance criteria, and check designs against them, such as how tokens are stored and how network trust is configured.
Carry it forwardTurn MASVS controls into design requirements.
Weak answerOnly using it at pentest time.
Constraint changes
What about resilience controls?
Does resilience protect secrets reliably?
Resilience against reverse engineering raises attacker cost but must not replace server-side controls. Use it where the threat model justifies it, such as reducing automated fraud.
Carry it forwardResilience raises cost; server controls protect value.
Weak answerRelying on resilience for security.
Constraint changes
How do you verify compliance?
Which checks can be automated?
Automated checks in CI where possible (static analysis, configuration checks), plus periodic manual testing guided by MASTG, with findings mapped back to MASVS controls.
Carry it forwardAutomate what you can, test the rest manually.
Weak answerAnnual pentest as the only check.
Now defend it
How would you apply MASVS?
Select the MASVS controls relevant to a payments app, turn them into design requirements and acceptance criteria, automate checks in CI, test with MASTG procedures periodically, map findings to controls, and use resilience controls only as a cost-raising layer behind server-side enforcement.
How it's scored
Weak: "MASVS is the mobile OWASP Top 10."
Hire: Distinguishes MASVS (requirements) from MASTG (tests), names most control groups, and uses them as a checklist for testing.
Strong Hire: Scopes by assets and threats, maps them to specific control groups, prioritises, includes the backend, treats resilience as risk-dependent, and reports findings against controls with preconditions and impact.
Common mistakes
- Testing every control with equal effort.
- Confusing MASVS with the separate OWASP Mobile Top 10 awareness list.
- Ignoring the backend APIs the app calls.
- Treating a failed resilience check as automatically high severity.