OWASP's mobile project is three documents in a chain. The MASVS sets requirements, the MASWE enumerates the weaknesses that break those requirements, and the MASTG describes how to test for those weaknesses. Read them in that order and you get from a goal to a concrete test.
The chain in one line
The OWASP project README puts it this way: MASVS leads to MASWE, which leads to MASTG. The MASVS "establishes baseline security and privacy requirements for mobile apps that are broken down in the OWASP Mobile Security Weakness Enumeration (MASWE) and tested in the OWASP Mobile Application Security Testing Guide."
The MASTG README describes itself as a manual for mobile app security testing and reverse engineering, and says it describes technical processes for verifying MASWE weaknesses, which align with MASVS controls.
What each document is good for
MASVS, the standard. Short controls such as "the app securely stores sensitive data". It is stable and readable by managers, buyers and auditors. Use it to set scope and to report status.
MASWE, the weakness list. A numbered set of weakness entries grouped under the same MASVS categories. Use it when a control is too broad to act on. It answers the question: what exactly goes wrong when this control fails?
MASTG, the testing guide. The how. It has platform sections for Android and iOS, general concepts and individual tests. Use it when you or a tester need steps to check a specific weakness on a device.
A worked path
Say your goal is MASVS-STORAGE-2, which says the app prevents leakage of sensitive data. That control description points to unintentional exposure through side effects of APIs and system features such as backups and logs.
- Find the weaknesses listed under that control in the MASWE.
- For each, pick the related tests in the MASTG for the platforms you ship.
- Run them on a build close to release, record the result, and file fixes.
- Report the control as met or not met against the MASVS wording.
Common mistakes
- Treating the MASVS as a test plan. It is not detailed enough to test from. The control text is intentionally short.
- Skipping the weakness layer. Teams jump from a vague control to a scanner report and cannot explain what a finding means for the control.
- Testing only one platform. Android and iOS fail in different ways. The MASTG separates them for that reason.
- Testing once. New libraries and new features change the answers. Rerun the relevant tests when they change.
Where Safeguard fits
Component checks fall under MASVS-CODE-3. Safeguard's SBOM and dependency scanning can show known vulnerable libraries in your build, and policies and gates can stop a release that breaks your rules. Try a free scan. Device level testing from the MASTG remains hands on work.
Quick check
Which document do I show a customer?
Usually the MASVS control list with your met, not met and not applicable status. It is short and the buyer can read it without mobile expertise.
Do I need to read the whole MASTG?
No. Start from the MASVS controls that matter for your app and read only the related tests.
Sources
- OWASP MASVS repository README
- OWASP MASTG repository README
- OWASP MAS site navigation (MASWE, MASTG)
Last reviewed: 19 October 2026.
