Mobile Application Security Assessment: An OWASP MASVS Checklist
A mobile app carries risks a web app does not, for one blunt reason: the attacker owns the device. Your APK or IPA sits on a phone that can be rooted, jailbroken, instrumented with Frida, and decompiled at leisure. Everything you ship inside the binary — keys, endpoints, logic, the data you cache locally — is in the hands of whoever wants to look. That single fact is why testing a mobile app against a web checklist misses most of what matters, and why OWASP built a mobile-specific standard.
This guide covers what the OWASP MASVS actually asks for after its 2.0 rewrite, how it pairs with the MASTG for the actual testing, and where it bites for Indian apps under RBI, SEBI and DPDP. It is written for product and security teams who need a mobile assessment that finds real issues, not a scan report that could have been run against any app.
What MASVS is now — and what changed in 2.0
The OWASP Mobile Application Security Verification Standard (MASVS) is the industry reference for what a secure mobile app should do. The 2.0 release (2023) was a significant restructure, and anyone still describing MASVS as "Levels 1, 2 and 3" is working from the old version. MASVS 2.0 dropped the numbered per-requirement levels and reorganised the standard around eight control groups, each describing an outcome rather than a checkbox:
- MASVS-STORAGE — sensitive data is stored and exposed safely on the device (the single most common source of real mobile findings).
- MASVS-CRYPTO — cryptography is implemented and keys are managed correctly, not hand-rolled.
- MASVS-AUTH — authentication and authorisation are enforced where they must be: on the server, not just in the app.
- MASVS-NETWORK — network traffic is secured, with certificate handling that actually resists interception.
- MASVS-PLATFORM — platform APIs (IPC, WebViews, deep links, the keyboard, screenshots) are used safely.
- MASVS-CODE — the app is built on secure coding practices and keeps its dependencies patched.
- MASVS-RESILIENCE — the app resists reverse engineering and tampering (relevant for high-value apps, not a substitute for the controls above).
- MASVS-PRIVACY — new in 2.0: the app handles user data with the minimisation and transparency privacy regimes now demand.
The addition of MASVS-PRIVACY as a first-class group is not cosmetic. It reflects that for a mobile app, privacy and security are now assessed together — which, for an Indian app under the DPDP Act, is exactly the right framing.
MASVS says what; MASTG says how
The common confusion is between the standard and the test. MASVS defines the security requirements. The OWASP Mobile Application Security Testing Guide (MASTG) is the companion that tells a tester how to verify each one, with concrete techniques for Android and iOS. The verification levels people remember — L1 (standard), L2 (defence-in-depth for sensitive apps) and R (resilience against reverse engineering) — now live in the MASTG as testing profiles, not in MASVS itself. A credible mobile assessment picks the profile that matches the app's risk: a payments or banking app earns L2 plus R; an internal tool may need only L1.
Where mobile assessments actually find things
After the architecture and scoping work, a real test runs static and dynamic analysis on a rooted/jailbroken device, and the serious findings cluster in a handful of places every time:
- Insecure local storage: tokens, PII and card data left in SharedPreferences, plist files, SQLite databases or logs in the clear — recoverable the moment the device is compromised.
- Secrets in the binary: API keys, signing keys and backend URLs hardcoded into the app and trivially extracted by decompilation.
- Server trusting the client: the mobile equivalent of the thick-client problem — authorisation or business rules enforced in the app but not re-checked by the API behind it. The app can be instrumented to send anything.
- Weak transport security: missing or bypassable certificate pinning, letting an attacker on the network read and modify traffic.
- Unsafe platform surface: exported components, insecure WebViews, and deep links that let another app on the device trigger privileged actions.
- Over-collection and leakage: data gathered or shared beyond what the app needs or discloses — the MASVS-PRIVACY and DPDP overlap.
Notice that most of these are invisible to a scanner. They require a tester on an instrumented device reasoning about what the app trusts and what it leaks — which is the whole point of a MASVS/MASTG-based assessment over an automated APK scan.
Where it meets Indian regulation
For an Indian mobile app, the standard is evidence for specific obligations. RBI's expectations for mobile banking and payment apps, SEBI's requirements for trading apps, and the DPDP Act's reasonable-safeguards and data-minimisation duties all land squarely on the storage, auth, network and privacy control groups. A MASVS-aligned assessment with the right MASTG profile, run by a CERT-In empanelled firm and closed out with retest evidence, is among the cleanest ways to show a regulator or an enterprise customer that the app was tested properly rather than scanned.
Frequently asked questions
FAQs
Is MASVS still based on Levels 1, 2 and 3?
No. MASVS 2.0 (2023) removed the numbered per-requirement levels and reorganised the standard into eight control groups (storage, crypto, auth, network, platform, code, resilience, privacy). The familiar L1/L2/R now exist as testing profiles in the MASTG, applied according to the app's risk — not as levels inside MASVS itself.
What is the difference between MASVS and MASTG?
MASVS is the standard — it defines what a secure mobile app must achieve. MASTG is the testing guide — it tells a tester how to verify each requirement on Android and iOS, with concrete techniques. A proper assessment uses MASVS as the yardstick and MASTG as the method.
Why can't an automated APK scanner do this?
Scanners catch known-vulnerable libraries and some obvious misconfigurations, but the serious mobile findings — insecure local storage, server trusting the client, bypassable pinning, unsafe platform components — need a tester on a rooted or jailbroken device reasoning about what the app trusts and leaks. That judgement is not automatable.
Does MASVS apply to both Android and iOS?
Yes. MASVS is platform-agnostic; the MASTG then provides platform-specific techniques for each. A full assessment typically covers both builds of the app, since the storage and platform risks differ between the two.
How does this help with DPDP compliance?
The MASVS-PRIVACY control group and the storage and network groups map directly onto DPDP's reasonable-safeguards and data-minimisation duties for a mobile app. A documented, closed-out assessment is strong evidence that personal data on the device and in transit is actually protected, not just claimed to be.
The bottom line
Mobile security starts from the fact that the attacker holds the device, and a real assessment tests for exactly that — on a rooted or jailbroken phone, against the current MASVS 2.0 control groups, using MASTG techniques at a profile that matches the app's risk. If your provider is still talking in MASVS "Levels 1-3" or shipping an automated APK scan, you are not getting that. CyberSigma runs CERT-In empanelled mobile application security assessments on the MASVS 2.0 / MASTG basis, for Android and iOS, with retest to closure. Book a free scope review for your app.
Liked the post? Share on:
Leave A Comment