Mobile owasp masvs

OWASP MASVS Alignment

Instructions

MASVS v2 is the de-facto standard for mobile app security. Use it as a verification checklist, not as a wish list — not every control applies to every app.

1. The Eight Groups (MASVS v2)

Group	Scope
MASVS-STORAGE	Sensitive data at rest.
MASVS-CRYPTO	Cryptography usage.
MASVS-AUTH	Authentication and session management.
MASVS-NETWORK	Network communication.
MASVS-PLATFORM	Platform interaction (IPC, WebViews, permissions).
MASVS-CODE	Code quality and update hygiene.
MASVS-RESILIENCE	Reverse-engineering and tampering resistance.
MASVS-PRIVACY	Privacy of user data.

Adopted in v2: RESILIENCE and PRIVACY are now explicit groups.

2. Pick a Profile

MASVS defines profiles, not a monolith:

• L1 (baseline) — every mobile app.
• L2 (defense-in-depth) — apps handling sensitive data (banking, health, enterprise).
• R (resilience) — apps at material risk of client-side attacks (DRM, gambling, premium content).

A SaaS productivity app may be L1. A consumer bank is L2 + R. Document which profile applies per app and per feature.

3. Control Mapping to Practical Skills

MASVS group	Map to skill
STORAGE	secure-storage, keystore-keychain, encrypted-databases
CRYPTO	keystore-keychain
AUTH	oauth-mobile, token-storage, biometric-auth, mfa-on-mobile
NETWORK	tls-pinning, mitm-prevention, api-abuse-protection
PLATFORM	mitm-prevention (WebView / deep links), secrets-management
CODE	code-obfuscation, dependency-scanning
RESILIENCE	anti-tampering, root-jailbreak-detection
PRIVACY	privacy-by-design, consent-management, gdpr-mobile

4. Practical Verification — Quick Wins

Run these on every release:

• Static: MobSF (open source) on the APK / IPA. Triage the findings — not every "HIGH" matters for your profile.
• Dependency: see dependency-scanning.
• Dynamic: run against Frida / Objection to validate root / debugger / pinning controls in a lab.
• Binary: apkanalyzer, otool -L, strings — sanity-check that no hardcoded secrets slipped in.

# Example: fail CI if an expected-stripped symbol is present
if unzip -p app-release.aab AndroidManifest.xml | grep -i "DEBUG"; then
  echo "Debug symbol shipped in release bundle" && exit 1
fi

5. Evidence Package Per Release

For L2 / R apps, produce a short evidence bundle:

• Which profile applies.
• Which MASVS controls are in scope, and which skill / test proves each.
• Exceptions, with a rationale and expiry date.
• Sign-off from engineering + security owner.

This pays for itself on the first audit, SOC 2 report, or App Store rejection.

6. What MASVS Does Not Cover

• Server-side authorization (covered by OWASP ASVS + API Security Top 10).
• Business-logic fraud (rate limits, anomaly detection).
• Supply-chain compromise of build tooling (covered by SLSA / in-toto).

Don't pretend MASVS compliance covers these — it doesn't.

7. Keep Up With the Standard

MASVS v2 is stable but the MASTG (Mobile Application Security Testing Guide) is updated continuously. Subscribe to releases; controls are refined as platforms change (e.g., iOS Privacy Manifests, Android 14 photo picker).

8. Using MASVS With AI Agents

When reviewing a PR, prompt the agent:

"Walk through this diff against MASVS-STORAGE and MASVS-NETWORK. List any control where you would fail or need more info."

Agents with these skills produce useful, specific findings — not generic "consider security" comments.

Checklist

• A profile (L1 / L2 / R) is documented per app and per feature.
• Each in-scope MASVS control maps to a specific skill or test.
• MobSF (or equivalent) runs on every release build and findings are triaged.
• Dynamic tests (Frida, Objection) verify resilience controls for R-profile features.
• Binary sanity checks run in CI (no hardcoded secrets, no debug symbols).
• Release produces an evidence bundle for L2 / R apps.
• MASTG updates are reviewed at least quarterly.