Contents
- What a mobile app pentest means
- The 8 MASVS groups
- MAS profiles: how strictly to test
- Which profile fits you
- The main risks: the OWASP lists for mobile and APIs
- What matters on each platform
- Pinning, root detection and obfuscation: what they protect and what not
- Mobile payments and the NBM
- How a mobile pentest runs
- Frequently asked questions
- Sources
In 30 seconds
- The reference standard is OWASP MASVS v2.1.0 (January 2024): 8 groups and 24 controls, from data storage to privacy 12.
- The tests are in MASTG v2.0.0 (July 2026), the first stable release of the rebuilt framework: 285 tests linked to controls through the MASWE weaknesses 37.
- The old L1/L2/R levels became MAS profiles: L1, L2, R and P. For a banking app, the OWASP example is L2+P+R 4.
- Root/jailbreak detection and obfuscation are defence in depth, not a security control: their absence is not in itself a vulnerability 6.
- An attacker who controls the phone reaches the server anyway: that is why the backend API is always in the test 1013.
What a mobile app pentest means
A mobile app has two halves: the code running on the user’s phone — in the hands of anyone who downloads it — and the servers it talks to. The test covers both. The OWASP testing guide says dynamic analysis covers both the app on the mobile platform and the backend services and APIs, and recommends access to the source code; “gray-box” testing is the most common 9.
| OWASP MAS project | What it is | Version |
|---|---|---|
| MASVS | The standard: what the app must meet — 8 groups, 24 controls | v2.1.0, 18 Jan 2024 2 |
| MASWE | The weakness catalogue: 78, linked to controls | v1.0.0, 17 Aug 2026 7 |
| MASTG | The testing guide: 285 tests, with techniques, tools and demos; each test has a clear pass/fail criterion | v2.0.0, July 2026 3 |
The 8 MASVS groups
Open each group: what the standard requires and what the tester checks in practice 12.
STORAGEData storageMASVS-STORAGE-1–2
- What it requires
- Sensitive data on the phone is stored securely and does not leak into logs, backups or screenshots.
- What we check
- What remains on the device after login and after logout: files, local databases, Keychain or Keystore, logs.
CRYPTOCryptographyMASVS-CRYPTO-1–2
- What it requires
- Current cryptography, used correctly, and keys managed across their whole life cycle.
- What we check
- Algorithms, modes, keys hard-coded or easy to extract from the app.
AUTHAuthentication and authorizationMASVS-AUTH-1–3
- What it requires
- Secure protocols with the server, local authentication (biometrics) used correctly, and extra steps for sensitive operations.
- What we check
- Whether biometrics merely “unlock a screen” or actually a key; whether the server checks permissions itself, not the app.
NETWORKNetwork communicationMASVS-NETWORK-1–2
- What it requires
- Traffic is protected and, where needed, the app pins the identity of its own servers.
- What we check
- Traffic interception, certificate validation, exceptions in ATS and the Android network configuration.
PLATFORMPlatform interactionMASVS-PLATFORM-1–3
- What it requires
- Communication with other apps (IPC), WebViews and the user interface are used securely.
- What we check
- Exported Android components, deep links, JavaScript bridges in WebViews, data visible in background snapshots.
CODECode qualityMASVS-CODE-1–4
- What it requires
- An up-to-date platform, forced updates when needed, components without known vulnerabilities, validated input.
- What we check
- Third-party libraries and SDKs, the minimum OS version, what happens with unexpected data.
RESILIENCEResilience against reverse engineeringMASVS-RESILIENCE-1–4
- What it requires
- Platform integrity, anti-tampering and making static and dynamic analysis harder — as defence in depth.
- What we check
- How quickly root/jailbreak detection, integrity checks and anti-debugging protections can be bypassed.
PRIVACYPrivacyMASVS-PRIVACY-1–4
- What it requires
- Data minimisation, unlinkability, transparency and user control over their data.
- What we check
- What the app and its SDKs collect compared with what they declare in the store and the privacy policy.
MAS profiles: how strictly to test
Since MASVS v2.0.0, levels are no longer in the standard: they became testing profiles applied to the MASTG tests 24. The profile is chosen by who the attacker is.
| Profile | Who the attacker is |
|---|---|
| MAS-L1 Essential | Other apps on the phone; the operating system is intact 4 |
| MAS-L2 Advanced | The operating system is not trusted; physical access is possible. Recommended for apps that touch card data or move money 5 |
| MAS-R Resilient | The user themselves: a reverse engineer or a cheater 4 |
| MAS-P Privacy | Not attacker-centred: protection of personal data 4 |
Profiles combine. OWASP gives L1+P, L1+P+R, L2+P and L2+P+R as examples — the last one for banking apps 4.
Which profile fits you
Which MAS profile fits your app?
Indicative, based on the OWASP MAS profiles. We settle the final profile together, from your threat model.
MAS-L1 + MAS-P
- MAS-L1 — essential security: other apps on the phone are adversaries; the operating system is assumed intact.
- MAS-L2 — advanced security: the operating system is not trusted and the attacker may have physical access to the phone. OWASP recommends it for financial apps.
- MAS-P — baseline privacy: what data the app and its SDKs collect, and whether the user controls it.
- MAS-R — resilience: the user may be the attacker; we test how well the app resists reverse engineering and tampering — on top of L1/L2, not instead.
We check all 8 MASVS groups; the profile decides how strictly.
- The backend API is in scope: the app’s requests are replayed and modified directly, without the app.
- Android: exported components, WebViews, network configuration, Keystore, Play Integrity verdicts checked on the server.
- iOS: ATS exceptions, Keychain, URL schemes, App Attest checked on the server.
- Two platforms mean two apps to test; the shared API is tested once.
The main risks: the OWASP lists for mobile and APIs
The awareness list for mobile apps, in its final 2024 release 12:
- M1 Improper Credential Usage
- M2 Inadequate Supply Chain Security
- M3 Insecure Authentication/Authorization
- M4 Insufficient Input/Output Validation
- M5 Insecure Communication
- M6 Inadequate Privacy Controls
- M7 Insufficient Binary Protections
- M8 Security Misconfiguration
- M9 Insecure Data Storage
- M10 Insufficient Cryptography
For the backend, the API Security Top 10 — 2023 applies, and it explicitly names mobile apps. First place goes to BOLA — broken object level authorization: change an ID in a request and get another customer’s data 13.
What matters on each platform
| Platform | Topic | What the official documentation says |
|---|---|---|
| Android | Exported components | With android:exported="true", any app can launch the component; the attribute must be declared explicitly 14 |
| Android | WebView | addJavascriptInterface exposes the native object to every frame in the WebView, with no origin check 15 |
| Android | Network configuration | Cleartext traffic blocked by default since Android 9; since API 24, default trust only in system certificate authorities 16 |
| Android | Play Integrity | Verdicts on the app, device and account; Google says not to use it as the sole anti-abuse mechanism, and the nonce is handled on the server 17 |
| iOS | App Transport Security | On by default; requires TLS 1.2 or later; some exceptions need justification for App Store review 18 |
| iOS | Keychain | The encrypted database for “small chunks of data”: passwords, keys, certificates 19 |
| iOS | App Attest | A key generated in the Secure Enclave and attested by Apple; verification happens on the server, and not every device supports it 20 |
Pinning, root detection and obfuscation: what they protect and what not
Pinning binds the app to its own servers’ certificate. MASTG says its absence should not be reported as a vulnerability, but that it is mandatory for MAS-L2; and that an attacker who controls the device can disable it, so it does not protect the server 10. When the app uses the standard APIs, bypassing it takes seconds with tools such as Frida or objection — which is why testers do it first, to see the traffic 11. Apple wrote in 2021 that in most cases pinning is not necessary 21.
Mobile payments and the NBM
For payments, strong customer authentication requires independent authentication elements. When the phone is a “multi-purpose device” — running both the app and receiving the code — separate secure execution environments, mechanisms ensuring the software or device has not been altered, and mitigation if it has are mandatory (RTS (EU) 2018/389, Art. 9) 22. In the Republic of Moldova, the NBM regulation on strong authentication (Decision No. 12/2024) reproduces these requirements in points 16–17 23.
The NBM ICT regulation requires penetration tests of critical systems at least every 3 years and security testing when launching new internet-facing systems (points 33.2, 33.5) — a mobile banking app falls under both 24. Testing on the MAS-L2 profile answers directly to the anti-tampering mechanisms required by Art. 9.
Stores require transparency too: Google Play requires the Data safety section from every app, third-party SDKs included 25, and Apple requires a declared reason for “required reason” APIs in the privacy manifest 26. The MAS-P profile checks whether what you declare matches what the app collects.
How a mobile pentest runs
- Profile and scope
We agree the MAS profile, platforms, versions and backend APIs; we receive test builds and accounts for every role.
- Static analysis
Decompilation and review: keys in code, exported components, network configuration, libraries with known vulnerabilities.
- Dynamic analysis
The app running on test devices: traffic interception, what remains stored, behaviour under root/jailbreak.
- The backend API
Requests replayed without the app: object- and function-level authorization, authentication, limits.
- Report and retest
Each finding with its MASVS control, severity, evidence and fix; the retest on the new build closes them.
Frequently asked questions
Which standard is used for mobile app pentesting?
What do MAS-L1, MAS-L2, MAS-R and MAS-P mean?
Is missing pinning a vulnerability?
Does root/jailbreak detection protect our app?
Do you also test the API behind the app?
Sources
Every statement about a law or standard links to its official source. Consulted on the date shown.
- OWASP MASVS — Mobile Application Security Verification Standard (accessed 23 Oct 2026)mas.owasp.org · accessed 23 October 2026
- OWASP MASVS v2.1.0 (18 Jan 2024) — release and controlsgithub.com · accessed 23 October 2026
- “MASTG v2.0.0 is Here” — OWASP MAS announcement (4 Jul 2026)mas.owasp.org · accessed 23 October 2026
- OWASP MAS — testing profiles (MAS-L1, MAS-L2, MAS-R, MAS-P) (accessed 23 Oct 2026)mas.owasp.org · accessed 23 October 2026
- OWASP MAS — the MAS-L2 profile (accessed 23 Oct 2026)mas.owasp.org · accessed 23 October 2026
- OWASP MASVS-RESILIENCE (accessed 23 Oct 2026)mas.owasp.org · accessed 23 October 2026
- OWASP MASWE v1.0.0 (17 Aug 2026) — mobile app weaknessesgithub.com · accessed 23 October 2026
- OWASP MAS — checklist removal (14 Jul 2026)mas.owasp.org · accessed 23 October 2026
- OWASP MASTG — mobile app security testing (static and dynamic analysis) (accessed 23 Oct 2026)mas.owasp.org · accessed 23 October 2026
- OWASP MASTG — testing network communication (pinning) (accessed 23 Oct 2026)mas.owasp.org · accessed 23 October 2026
- OWASP MASTG-TECH-0012 — bypassing certificate pinning on Android (accessed 23 Oct 2026)mas.owasp.org · accessed 23 October 2026
- OWASP Mobile Top 10 (2024)owasp.org · accessed 23 October 2026
- OWASP API Security Top 10 — 2023owasp.org · accessed 23 October 2026
- Android — the android:exported riskdeveloper.android.com · accessed 23 October 2026
- Android — insecure WebView native bridgesdeveloper.android.com · accessed 23 October 2026
- Android — network security configurationdeveloper.android.com · accessed 23 October 2026
- Android — overview of the Play Integrity APIdeveloper.android.com · accessed 23 October 2026
- Apple — preventing insecure network connections (ATS)developer.apple.com · accessed 23 October 2026
- Apple — Keychain Servicesdeveloper.apple.com · accessed 23 October 2026
- Apple — establishing your app’s integrity (App Attest)developer.apple.com · accessed 23 October 2026
- Apple Developer News — on identity pinning (14 Jan 2021)developer.apple.com · accessed 23 October 2026
- Commission Delegated Regulation (EU) 2018/389 (RTS on strong customer authentication)eur-lex.europa.eu · accessed 23 October 2026
- NBM — Regulation on strong customer authentication (Decision No. 12/2024)bnm.md · accessed 23 October 2026
- NBM — Regulation on minimum requirements for ICT risk management (Decision No. 29/2025)bnm.md · accessed 23 October 2026
- Google Play — the Data safety sectionsupport.google.com · accessed 23 October 2026
- Apple — describing use of required reason APIs in the privacy manifestdeveloper.apple.com · accessed 23 October 2026
About the authors
The guides are written by the team that does the testing, not a marketing department. We update them when the law, the standard or what we see in testing changes.