OWASP MASVS/MASTG for Android: A Practical Checklist

If you've ever been handed a mobile app and told "make sure it's secure" without much more guidance than that, you already know the problem: mobile security isn't one thing. It's storage, crypto, auth, network, platform integration, code quality, and resilience against reverse engineering — all at once, all interacting with each other.

That's exactly the gap OWASP's Mobile Application Security project fills. This post is the map for a series we'll be building out over the coming weeks — each entry below gets its own deep dive (network config, certificate pinning, secure logging, the Keystore, and more). Consider this the checklist you pin to the top of your PR template.

MASVS, MASTG, and MASWE — what's what

Three documents, three jobs:

• MASVS (Mobile Application Security Verification Standard) — the what. A list of security requirements, each with an ID like MASVS-STORAGE-1, organized into categories.
• MASTG (Mobile Application Security Testing Guide) — the how. Step-by-step test cases mapped to each MASVS control, with tooling and platform-specific instructions for Android and iOS.
• MASWE (Mobile Application Security Weakness Enumeration) — the what-can-go-wrong. A catalog of weaknesses, mapped back to both of the above.

In practice you rarely test against MASVS prose directly. You pick a MASTG security testing profile — MAS-L1, MAS-L2, or MAS-R — that matches your app's risk level, pull the in-scope controls for that profile, and run the corresponding MASTG tests, mapping any findings to MASWE weaknesses.

If you've seen older material referencing "L1 / L2 / R verification levels" baked into MASVS itself, that's the v1 model. Since the v2.0.0 refactor, levels live in the MASTG as testing profiles, not in the MASVS as verification tiers — worth knowing so you're not cross-referencing a deprecated structure.

As of this writing, MASVS is at v2.1.0 (January 2024), with 8 categories and 24 controls total. Earlier in 2026, the MASTG project completed its multi-year v2 refactor: the guide is now built from individually referenceable, machine-readable test components with automated demos, replacing the old monolithic v1 tests. If a resource you're reading references "MSTG" instead of "MASTG," or cites L1/L2/R as MASVS levels, treat it as outdated and go straight to the official mas.owasp.org site.

The 8 MASVS categories, at a glance

Category Covers Series post

STORAGE : Sensitive data at rest — SharedPreferences, databases, files, backups Planned

CRYPTO : Correct use of cryptographic primitives and key management Android Keystore deep dive

AUTH : Authentication, session handling, authorization boundaries Planned

NETWORK : Data in transit — TLS config, pinning, trust management Network Security Config + cert pinning

PLATFORM : Safe interaction with IPC, intents, WebViews, other apps Planned

CODE : Build hardening, memory safety, third-party dependency risk Planned

RESILIENCE : Anti-tampering, root/jailbreak detection, obfuscation Planned

PRIVACY : Data minimization, consent, data handling transparency (added in v2.1.0) Planned

Note that PRIVACY is the newest addition — it landed in v2.1.0 as the only change from v2.0.0, so if you're working from an older internal checklist, this category is worth auditing for specifically.

A practical checklist to start with

You don't need to boil the ocean on day one. Here's a reasonable on-ramp, roughly in the order most Android teams get value from it:

1. Pick your profile first. Before touching a single control, decide: is this a MAS-L1 app (baseline hygiene — most apps) or MAS-L2 (defense-in-depth — banking, health, anything handling regulated or highly sensitive data)? This decision scopes everything downstream and keeps you from over-engineering a to-do list app or under-engineering a payments app.

2. Storage — audit before you build. Grep your codebase for SharedPreferences, SQLiteOpenHelper, and raw file writes. Anything holding tokens, PII, or credentials in plaintext is your first finding, every time.

3. Network — assume MITM by default. Confirm cleartext traffic is disabled via Network Security Config, TLS is enforced app-wide (not just for "sensitive" endpoints), and certificate/public-key pinning is in place for high-value connections. We covered pinning in production already — link below.

4. Crypto — check what's actually generating and storing your keys. This is where "I used AES" isn't the same as "I used AES correctly." Mode, IV handling, and whether keys ever touch app-controlled storage instead of the Android Keystore are the recurring failure points.

5. Auth — session and token lifecycle, not just login. Where do tokens live after login? Are they invalidated server-side on logout? Is biometric auth actually gating a cryptographic operation, or just a UI gate a rooted device can skip?

6. Platform — exported components and IPC. Run through your manifest for exported activities, services, and receivers without permission checks. Check WebView configurations for JavaScript bridges exposed to untrusted content.

7. Logging — the quiet leak. Crash reporters and Logcat are two of the most common places sensitive data leaks without anyone noticing during a normal QA pass. We'll cover this in depth shortly.

8. Resilience — last, not first. Root detection, tamper checks, and obfuscation matter, but they're the last line of defense, not a substitute for fixing the categories above. Don't let resilience work become a way to avoid harder storage or auth fixes.

Where to actually run this

• mas.owasp.org — the canonical source for MASVS, MASTG, and MASWE. Bookmark this over any blog summary (including this one) for anything you plan to cite in an audit.
• MAS Checklist — a spreadsheet/webpage that maps every MASVS control directly to its MASTG test cases. This is the fastest way to turn "we should check crypto" into an actual repeatable test.
• MASTG v2 atomic tests — individually referenceable test cases with automated demos where available, useful if you're building this into CI rather than running it as a one-time audit.

What's next in this series

This post is the map. Next up, we go one level deeper into the NETWORK category:

• Network Security Config, deep dive
• Certificate pinning in production
• Secure logging — what should never hit Logcat or your crash reporter
• Android Keystore, deep dive

If your team is starting from zero, the honest advice is: pick MAS-L1, run the storage and network checks this week, and build from there. Perfect MASVS compliance on day one is less valuable than steady, verifiable progress against a standard everyone on the team can point to.