OWASP MAS: The Standard for Auditing Mobile Application Security

OWASP MAS (Mobile Application Security) is OWASP's project for mobile application security. It turns Android and iOS security assessment into a systematic, repeatable process: MASVS defines what a secure app should satisfy, MASWE describes the weaknesses that can break those requirements, and MASTG explains how to verify them with technical tests.

If you are looking for a practical reference for mobile pentesting, security reviews, secure development, or pre-production assessment, OWASP MAS is one of the best places to start. This guide explains how MASVS, MASWE and MASTG fit together, what changed in 2026, how to use them in a real assessment, and which tools are commonly involved.

In this guide

• What is OWASP MAS?
• MASVS vs MASWE vs MASTG
• What changed in OWASP MAS in 2026
• The 8 OWASP MASVS control groups
• How to use OWASP MAS in a mobile security assessment
• Common weaknesses by MASVS category
• Mobile security testing tools
• Android vs iOS
• What happened to the OWASP MAS Checklist?
• OWASP MAS for pentesting and bug bounty
• How to get started
• FAQ

What is OWASP MAS?

OWASP Mobile Application Security (MAS) is the OWASP project focused on mobile application security. It is not a tool and it is not a certification. It is a set of open standards and technical resources that helps developers, architects and security testers assess Android and iOS applications consistently.

Its central resource is the OWASP MASVS (Mobile Application Security Verification Standard), which OWASP describes as the industry standard for mobile app security. MASVS groups security controls across storage, cryptography, authentication, network communication, platform interaction, code, resilience and privacy.

A high-level control, however, does not always tell a tester exactly which weakness to look for or how to verify it. That is where MASWE and MASTG come in.

This traceability chain is the clearest way to understand the project today: start with the security requirement, identify the weaknesses that can violate it, then select concrete and reproducible tests.

MASVS vs MASWE vs MASTG

MASVS: the standard — the “what”

MASVS defines security requirements. For example, MASVS-STORAGE-1 requires an app to store sensitive data securely. Its role is not to give you a command to run, but to define the security objective the application should meet.

MASWE: the weaknesses — how the requirement can fail

MASWE (Mobile Application Security Weakness Enumeration) is a catalogue of mobile-specific security and privacy weaknesses. It bridges MASVS controls and MASTG tests.

Storage-related weaknesses, for example, include sensitive data stored unencrypted, cryptographic keys kept outside the platform keystore, secrets hardcoded in the application package, and sensitive information written to logs.

MASTG: the testing guide — the “how”

MASTG (Mobile Application Security Testing Guide) provides platform-specific knowledge, techniques, tools, tests and demos for Android and iOS. It is the layer that turns the standard into assessment work.

With MASTG v2, traceability is much clearer: a test can be linked to a specific MASWE weakness and, from there, to the corresponding MASVS control.

What changed in OWASP MAS in 2026?

If you have been reading older mobile security material, three recent changes matter:

• MASTG v2.0.0: released in June 2026, it reorganized the testing guide around a modular model and linked tests to MASWE weaknesses.
• MASWE v1.0.0: released in August 2026, it established 78 stable, fully documented and consistently numbered weaknesses.
• MAS Checklist: the generated spreadsheet distributed with older MASTG releases is no longer included as an official MASTG v2 artifact.

You should also be careful with older material that still treats MASVS L1, L2 and R as current verification levels. Starting with MASVS 2.0, the standard no longer contains those verification levels, and the project has been moving toward MAS Testing Profiles.

The 8 OWASP MASVS control groups

These categories are a coverage map, not a requirement to run the exact same test set against every application. Scope should reflect the app's risk, functionality, data, platform and threat model.

How to use OWASP MAS in a mobile security assessment

A common mistake in mobile pentesting is to open jadx, Burp or Frida and start looking for anything suspicious without a coverage model. OWASP MAS lets you reverse that workflow: define what you want to verify first, then select the applicable tests.

1. Define scope and threat model. Identify Android/iOS versions, included functionality, sensitive data and relevant attack scenarios.
2. Select MASVS controls. Use them as the security objectives to assess.
3. Review MASWE. Identify the weaknesses that can violate each control.
4. Select MASTG tests. Run the relevant techniques for the target platform and version.
5. Document evidence and impact. Record the vulnerable condition, reproduction steps, evidence, risk and remediation.

Example: MASVS-STORAGE-1

Suppose you want to verify whether an application stores sensitive information securely. Instead of reducing the assessment to “check SharedPreferences”, inspect the weaknesses associated with the control and select the applicable tests.

# Your own application / training lab
$ adb shell
$ run-as com.example.demo
$ find . -type f | head

# Inspect preferences and databases
$ cat shared_prefs/auth.xml
$ find . -name "*.db" -o -name "*.sqlite"

If you find a persistent session token in cleartext, OWASP MAS adds value beyond the command itself: the evidence can be traced to the relevant weakness and to the MASVS control you intended to verify.

Common weaknesses by MASVS category

MASVS-STORAGE: insecure sensitive data storage

# Search sensitive values in a lab app
$ grep -RniE "token|password|secret|api[_-]?key" shared_prefs/ files/ databases/ 2>/dev/null

Common issues include cleartext session tokens, personal information in logs, secrets embedded in APK/IPA packages, backup leakage, and data written to inappropriate storage locations.

MASVS-CRYPTO: weak or incorrectly used cryptography

# Static review after decompiling your own APK
$ grep -RniE 'DES|AES/ECB|MD5|SecretKeySpec' ./sources/

The goal is not to flag every string containing “AES”. Review algorithm choice, mode of operation, key generation, key storage and the lifecycle of cryptographic material.

MASVS-AUTH: security decisions enforced only on the client

A critical pattern appears when the client makes a decision that should be enforced server-side: operation authorization, account state, access to another user's data, premium status, or session validity.

MASVS-NETWORK: insecure communications

# Android: inspect Network Security Config
$ grep -Rni "cleartextTrafficPermitted" ./res ./AndroidManifest.xml

Review TLS, certificate validation, network configuration, cleartext traffic and any additional controls used to protect sensitive communications.

MASVS-PLATFORM: WebViews, deep links and IPC

# Review exported components and deep links
$ grep -RniE 'exported="true"|android:scheme|android:host' AndroidManifest.xml

This area covers platform-specific attack surfaces: intents, activities, content providers, WebViews and App Links on Android; URL schemes, Universal Links, entitlements and related mechanisms on iOS.

MASVS-CODE: dependencies and unsafe data processing

This includes vulnerable or outdated dependencies, unsafe processing of attacker-controlled data, exposed debugging functionality and other code-level issues that affect the app's security posture.

MASVS-RESILIENCE: reverse engineering and tampering

Resilience testing evaluates controls against modification, instrumentation, debugging, hooking and binary analysis. The required depth depends on the threat model; not every application needs the same resilience measures.

MASVS-PRIVACY: user privacy

Review what personal information the app processes, which permissions it requests, which data it collects or shares, and whether the app provides the expected controls over user privacy.

Mobile security testing tools used with OWASP MAS

Android vs iOS: same standard, different attack surface

The standard provides the common security model; implementation of the tests is platform-specific. A tester must translate each MASVS objective into the actual Android or iOS mechanisms involved.

What happened to the OWASP MAS Checklist?

“OWASP MAS Checklist” still appears in search results and older material, but the project changed in 2026. Previous MASTG releases generated a spreadsheet that helped testers track MASVS controls and associated tests. With MASTG v2.0.0, that spreadsheet is no longer distributed as an official release artifact.

The need to track assessment coverage has not disappeared. The model is now better represented as:

Professional teams can still maintain their own coverage matrix in a spreadsheet, GRC platform or reporting system, using the applicable MASVS controls, MASWE weaknesses and MASTG tests as references.

OWASP MAS for pentesting and bug bounty

Mapping a finding to OWASP MAS does not replace impact analysis, but it can significantly improve reproducibility and technical clarity. It lets you explain which security objective failed, which weakness is present and how it was demonstrated.

In bug bounty, eligibility and severity depend on the program rules and demonstrated impact. Missing certificate pinning, root detection or a particular hardening control should not automatically be treated as a payable vulnerability without a security consequence that is in scope.

How to get started with OWASP MAS

1. Read the eight MASVS control groups to understand the overall security model.
2. Choose an approachable category such as MASVS-STORAGE.
3. Review the related MASWE weaknesses.
4. Find the applicable MASTG tests for Android or iOS.
5. Practice against a deliberately vulnerable, self-owned or training application.
6. Document each test and result as if it were a professional assessment.

If you come from web security, much of your knowledge still applies because mobile apps consume APIs and backend services where IDOR/BOLA, broken authentication, business logic issues, SSRF and authorization flaws still exist. The difference is that you must also assess the mobile client, local storage, platform integration and runtime behavior.

OWASP MAS, MASVS and MASTG FAQ

What is OWASP MAS?

It is OWASP's mobile application security project. It includes resources such as MASVS, MASWE and MASTG to define security requirements, classify mobile weaknesses and perform Android/iOS security testing.

What is OWASP MASVS?

OWASP MASVS is the Mobile Application Security Verification Standard. It defines mobile app security controls across eight areas: storage, crypto, auth, network, platform, code, resilience and privacy.

What is the difference between MASVS, MASWE and MASTG?

MASVS defines what the app should satisfy; MASWE describes which weaknesses can violate those requirements; MASTG explains how to test them using platform-specific knowledge, techniques and tests.

What is MASVS-STORAGE-1?

It is a MASVS storage control requiring the app to store sensitive data securely. A complete assessment should review the applicable MASWE weaknesses and MASTG tests rather than treating the control as a single test case.

Does the OWASP MAS Checklist still exist?

The spreadsheet distributed with older MASTG releases is no longer shipped as an official MASTG v2 artifact. Coverage is now better represented through MASVS → MASWE → MASTG traceability, while teams can maintain their own tracking matrix.

Does OWASP MAS cover both Android and iOS?

Yes. MASVS provides a common security model, while MASTG contains platform-specific knowledge and tests for Android and iOS.

Is OWASP MAS a certification?

No. OWASP MAS is an open OWASP project and a mobile security reference framework, not a professional certification or exam.

Do I need web hacking knowledge before learning mobile pentesting?

It is not mandatory, but it helps significantly. Mobile apps depend on APIs and backend services, so HTTP, authentication, authorization and web vulnerability knowledge lets you assess the complete system rather than only the client.

Official references

• OWASP Mobile Application Security
• OWASP MASVS
• OWASP MASWE
• OWASP MASTG
• MASWE v1.0.0 release