OWASP MAS: The Standard for Auditing Mobile Application Security

Almost every company has a mobile app, but auditing its security is still, in many places, an improvised process: everyone checks whatever comes to mind, with no shared criteria and no way of knowing whether everything has been covered. OWASP MAS exists for exactly that: it turns mobile app auditing into a repeatable discipline, with a standard that says what to check and a guide that says how to check it.

In this article I explain what OWASP MAS is, the three pieces that make it up, the categories of the standard, how it applies in a real audit, what tools are used, and how to put this knowledge to work in a professional context, which is exactly the way of working we teach in our mobile course.

In this guide

• What OWASP MAS is
• The three pieces of the project
• The MASVS categories
• How it is used in a real audit
• Typical vulnerabilities by category
• Essential tools for auditing with OWASP MAS
• Android and iOS: the same standard, a different surface
• From web to mobile: the natural bridge
• OWASP MAS in bug bounty and professional settings
• Where to start with OWASP MAS
• Frequently asked questions

What OWASP MAS is

OWASP MAS (Mobile Application Security) is the OWASP flagship project dedicated to mobile application security. It is not a tool or a course: it is the reference framework the industry uses to assess whether an Android or iOS app is secure, in a consistent and complete way.

Its great strength is that it separates two questions many people mix up: what needs to be verified and how it is verified. And to join them, it has added a third piece that acts as a bridge. The flow is this:

# The OWASP MAS flow
MASVS  →  MASWE  →  MASTG
 (what)    (weaknesses)   (how)

The three pieces of the project

MASVS: the standard (the "what")

The MASVS (Mobile Application Security Verification Standard) is the list of security requirements an app should meet. Each requirement has a clear identifier (for example MASVS-STORAGE-1) and a pass/fail criterion. It is the document that defines the goal of the audit: the reference you measure the app against.

MASWE: the weaknesses (the bridge)

The MASWE (Mobile Application Security Weakness Enumeration) is a more recent addition and the one many older articles do not mention. It is a catalogue of concrete, mobile-specific weaknesses that connects each MASVS requirement with the tests that verify it. It bridges the "what" of the MASVS and the "how" of the MASTG, like a map that says "this requirement can fail in these ways".

MASTG: the testing guide (the "how")

The MASTG (Mobile Application Security Testing Guide) is the complete technical manual. It covers everything from the inner workings of mobile operating systems to advanced reverse engineering, and contains concrete test cases (with identifiers such as MASTG-TEST-0001) that tell you what to look for, what tools to use, and how to reproduce the issue on both Android and iOS. It is the successor to the old MSTG, renamed in the 2023 restructuring.

And as practical support there is the MAS Checklist, which links each MASVS control with its MASTG test cases. It is the reference you will keep open throughout the audit, and it also serves compliance purposes.

The MASVS categories

The MASVS organizes its requirements into categories. Knowing them gives you the full mental map of what a serious mobile audit covers:

How it is used in a real audit

Here is the part that really matters. The typical mistake is to grab an app and start "poking around" with no method. With OWASP MAS the process is systematic and reproducible:

1. You start from a MASVS requirement you want to verify.
2. You look in the MASWE for the concrete weaknesses associated with that requirement.
3. You follow the MASTG test cases to verify them, step by step.
4. You document the finding with reproducible evidence.

A classic example is MASVS-STORAGE-1 ("the app securely stores sensitive data"). The MASTG tells you to inspect the app's data directory and review preferences, databases, and cache for sensitive information in cleartext. On one of your own apps, it looks like this:

# MASVS-STORAGE on one of your own apps
# Access the app's private data (on a test device)
$ adb shell
$ run-as com.miapp.demo
$ cat shared_prefs/auth.xml
<map>
  <string name="session_token">eyJhbGciOiJIUzI1NiIs...</string>
  ← session token stored IN CLEARTEXT: violates MASVS-STORAGE-1

What matters is not the command, it's the method: you start from a requirement, you know which weakness you are looking for, you verify it with a defined test case, and you document it with evidence. That is exactly how a professional audit works.

Typical vulnerabilities by category

Each MASVS category has a pattern of failures that recurs in real audits. Knowing them in advance lets you go straight to what most often breaks. We walk through all eight in the order of the standard.

MASVS-STORAGE: what shows up most

# Credentials in SharedPreferences (Android)
$ adb shell run-as com.target.app
$ find . -name "*.xml" | xargs grep -i "password\|token\|secret\|key"

# Unencrypted SQLite database
$ find . -name "*.db" -o -name "*.sqlite"
$ sqlite3 app_data.db ".tables"
$ sqlite3 app_data.db "SELECT * FROM users;"

# iOS: files in NSDocumentDirectory without protection
$ objection -g com.target.app explore
$ ios filesystem ls

The most common pattern: session tokens, passwords, or PII stored in SharedPreferences or in an unencrypted SQLite database. Developers put them there for convenience, without realizing that any app with backup permissions or a rooted device exposes them entirely.

MASVS-CRYPTO: weak cryptography and poorly managed keys

# Obsolete algorithms in the code (after decompiling with jadx)
Cipher.getInstance("DES")          ← obsolete cipher
Cipher.getInstance("AES/ECB/PKCS5Padding") ← insecure ECB mode
MessageDigest.getInstance("MD5")   ← broken hash

# Key hardcoded directly in the code
String key = "hardcoded_secret_key_123";
  ← key in the binary: anyone can extract it by decompiling the APK

# Search for keys and algorithms in the decompiled code
$ grep -rniE "secretkey|aes|des|md5|cipher" ./sources/

The typical pattern in cryptography: broken algorithms (DES, MD5), the ECB cipher mode, or keys hardcoded directly in the code. A key in the binary is equivalent to having no encryption at all, because it can be extracted simply by decompiling the app.

MASVS-AUTH: authentication validated only on the client

# Access validation only on the client
# (the app checks the PIN locally, without confirming it on the server)
if (enteredPin.equals(storedPin)) {
    grantAccess();
    ← can be bypassed by modifying the binary
}

# Bypassing biometric authentication with Frida
$ frida -U -f com.target.app -l biometric-bypass.js
# forces the success callback without a valid fingerprint

The most serious authentication flaw on mobile: validating the session or the PIN only on the client, with no server-side verification. If the "access granted" decision lives inside the app, it can be modified. The golden rule: all authentication and authorization must be confirmed on the server.

MASVS-NETWORK: misconfigured TLS and missing certificate pinning

# Intercept traffic with Burp Suite: set the proxy on the device
# If the app does not implement pinning, traffic appears in cleartext

# Bypassing pinning with Frida (on your own app in a test environment)
$ frida -U -f com.target.app \
    -l ssl-pinning-bypass.js \
    --no-pause

# Misconfigured Network Security Config (Android)
# res/xml/network_security_config.xml with:
<base-config cleartextTrafficPermitted="true">
  ← allows cleartext HTTP: violates MASVS-NETWORK-1

The most common network mistake: the app accepts any TLS certificate without validating it, or has network_security_config.xml set to allow cleartext HTTP traffic. In banking or healthcare apps this is critical.

MASVS-PLATFORM: mishandled WebViews and deep links

# WebView with JavaScript enabled and local file access
# In the source code (after decompiling with jadx):
webView.getSettings().setJavaScriptEnabled(true);
webView.getSettings().setAllowFileAccess(true);
← dangerous combination: LFI via JavaScript in the WebView

# Deep link without origin validation (AndroidManifest.xml)
<intent-filter>
  <data android:scheme="miapp" android:host="auth"/>
</intent-filter>
# Any app can open miapp://auth?token=ATTACKER_TOKEN

MASVS-CODE: vulnerable dependencies and unsafe data handling

# Dependencies with known vulnerabilities
$ grep -A2 "dependencies" build.gradle
# cross-check versions against CVE databases (OSV, Snyk)

# Insecure deserialization of untrusted data
ObjectInputStream in = new ObjectInputStream(untrustedData);
Object obj = in.readObject();
  ← reconstruction of an attacker-controlled object

# SQL injection in a Content Provider
content://com.target.app/users?id=1' OR '1'='1

This is where the classic server-side vulnerabilities, moved to the client, come in: outdated dependencies with known CVEs, insecure deserialization of attacker-controlled data, and SQL injection in components that accept external input.

MASVS-RESILIENCE: root/jailbreak detection and anti-tampering

# Check whether the app detects root (Android)
$ objection -g com.target.app explore
> android root disable

# Bypassing jailbreak detection on iOS with Frida
$ frida -U -f com.target.app \
    -l jailbreak-bypass.js

# If the app has no integrity controls,
# the APK can be repackaged with modified code:
$ apktool d target.apk
# modify smali / inject code
$ apktool b target_modified/
$ jarsigner -keystore debug.keystore target_modified.apk androiddebugkey

MASVS-PRIVACY: persistent identifiers and excessive permissions

# Persistent identifiers for user tracking
Settings.Secure.ANDROID_ID
telephonyManager.getImei()   ← persistent device identifier

# Excessive permissions in the manifest (AndroidManifest.xml)
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>
<uses-permission android:name="android.permission.READ_CONTACTS"/>
  ← does the app actually need these for its function?

# Personal data (PII) sent unencrypted: capture with Burp

The most recent category. It reviews the use of persistent identifiers for tracking, permissions the app does not need for its function, and the transmission of personal data without proper protection. Privacy is now a formal part of any serious mobile audit.

Essential tools for auditing with OWASP MAS

The MASTG references the tools in each test case. These are the ones that come up constantly in a real audit, organized by function:

The minimum test environment

# Android: rooted device or emulator
# Option 1: AVD with a Google APIs image (supports root)
$ emulator -avd Pixel_6_API_33 -writable-system

# Option 2: physical device with Magisk
# Enables Frida server and full file system access

# Install Frida server on the device
$ adb push frida-server /data/local/tmp/
$ adb shell "chmod +x /data/local/tmp/frida-server"
$ adb shell "/data/local/tmp/frida-server &"

# iOS: jailbroken iPhone (palera1n / checkra1n for compatible devices)
# Install Frida from Cydia/Sileo

Android and iOS: the same standard, a different surface

OWASP MAS covers both platforms with the same framework, but the attack surface changes quite a bit:

The standard gives you the common map; the skill lies in knowing how to translate each requirement into the technical reality of each platform. A good mobile audit looks at both.

From web to mobile: the natural bridge

There's a detail that surprises beginners: a huge share of a mobile app's flaws are not in the app, but in its API. IDOR, broken authentication, business logic, SQLi, SSRF... the same server-side vulnerabilities you already know from web hacking, now behind an app.

The difference is the client. On the web the client is a browser with DevTools and the whole request visible. On mobile the client is a compiled app, with its own logic, which may implement certificate pinning, traffic obfuscation, or local validations that you have to understand and bypass before reaching the API. That additional layer is what gets added to the web knowledge you already have.

That's why the natural path is to reach mobile with a web foundation. If you come from expert-level web exploitation with WXE, the jump to mobile with MXS is direct: you reuse everything you know about APIs and add the device-specific side (storage, platform, resilience, reverse engineering).

OWASP MAS in bug bounty and professional settings

Knowing OWASP MAS is not just knowing what to look for: it's knowing how to communicate what you find. In a professional setting (pentest, bug bounty, or internal audit) the difference between a finding that gets taken seriously and one that gets dismissed is not in the technique: it's in whether the auditor can map the problem to a recognized standard, demonstrate impact with reproducible evidence, and deliver something the client understands.

How bug bounty programs value mobile findings

Mature bug bounty programs (HackerOne, Intigriti, Bugcrowd) increasingly include mobile apps in scope. What sets apart a report that gets paid from one that gets closed as "informative":

Categories that show up most in mobile bug bounty

# The categories that generate the most valid findings in real programs:

# 1. MASVS-STORAGE: sensitive data in cleartext
#    - SharedPreferences, SQLite, logs, backups
#    - High frequency, impact varies with the data exposed

# 2. MASVS-NETWORK: missing or bypassed certificate pinning
#    - Allows intercepting and manipulating API traffic
#    - Often chained with API flaws (IDOR, broken auth)

# 3. MASVS-PLATFORM: deep links and WebViews
#    - Open redirect, XSS in WebView, access to local files
#    - High impact if the WebView has access to authenticated content

# 4. MASVS-AUTH: exposed tokens or broken authentication logic
#    - Token validation only on the client, no server-side check
#    - Very common in fintech and healthcare apps

Where to start with OWASP MAS

• Read the MASVS from start to finish once. It is short and gives you the complete map.
• Pick a category (start with MASVS-STORAGE, the most accessible) and practice its MASTG test cases on one of your own apps.
• Set up a minimum environment: Android with a rooted emulator or a device with Magisk, jadx for static analysis, Frida/Objection for dynamic, Burp for network.
• Use the MAS Checklist as a roadmap so you don't miss anything.
• Document every finding as if it were a real report from day one.

Frequently asked questions

What is the difference between MASVS, MASWE, and MASTG?

The MASVS defines the security requirements (the what), the MASWE catalogues the concrete associated weaknesses (the bridge), and the MASTG explains how to verify them with test cases (the how). The three together form the OWASP MAS project.

Does OWASP MAS work for both Android and iOS?

Yes. The standard is platform-independent; the MASTG test cases include guidance specific to each one. A complete audit covers both.

Do I need to know web hacking before getting into mobile?

It helps a lot. A good share of an app's flaws live in its API, which are the same server-side vulnerabilities as web hacking. Reaching mobile with that foundation makes the learning much faster and lets you chain client-side flaws with server-side flaws, which is where the real impact is.

Is OWASP MAS a certification?

No. It is a standard and a set of open, free resources. It is the framework used to audit, not an exam you pass.

Do I need a physical device or is an emulator enough?

To get started, an Android emulator with a rooted image is enough for most tests: static analysis, SQLite, SharedPreferences, WebViews, deep links. For advanced hardware tests (sensors, NFC, Bluetooth) or for iOS you need a physical device. The MASTG specifies in each test case whether there are limitations with an emulator.

How long does it take to master OWASP MAS?

It depends on your starting level. With a web hacking foundation you can have a basic Android audit working in weeks. The full professional level (Android + iOS, advanced reverse engineering, bypassing modern controls) requires sustained practice on real apps. MXS is designed to lead that process in a structured way and with a dedicated lab environment.

What is the difference between an OWASP MAS audit and a generic mobile pentest?

Coverage and reproducibility. A generic pentest tends to find whatever the auditor remembers to check that day. An OWASP MAS audit has a checklist of 100+ controls that ensures no category has been skipped. And each finding can be tied directly to a requirement of the standard, which makes communication with the client and later verification easier.

References

• OWASP MAS: official site of the mobile application security project.
• OWASP MASVS: the verification standard.
• OWASP MASTG: the testing guide with test cases.
• OWASP MASVS on GitHub: the standard's repository.