TL;DR
- ✓This checklist groups mobile pentest tests by the seven OWASP MASVS categories: Storage, Crypto, Auth, Network, Platform, Code, and Resilience.
- ✓MASVS-L1 is the baseline for any app; MASVS-L2 adds defense-in-depth for sensitive data; MASVS-R adds resilience (anti-tampering, anti-instrumentation) for high-risk apps.
- ✓Static checks use MobSF, jadx, apktool, and Hopper/Ghidra; dynamic checks use Frida, objection, Burp Suite, mitmproxy, and Drozer on a rooted or jailbroken device.
- ✓The highest-yield checks are insecure storage (cleartext tokens/PII), missing certificate pinning, and exported components or unvalidated deeplinks.
- ✓Each finding should be recorded with its MASVS control reference, a CVSS score, reproduction steps, and remediation.
The fastest way to miss a mobile vulnerability is to test without structure. This checklist is organized exactly the way the OWASP MASVS is, by control category, so you can work top to bottom and know precisely which control each test verifies.
Use it for both iOS and Android. Where the platforms diverge (Keychain vs Keystore, IPA vs APK), the test notes call it out. Pair this with our overview of mobile app penetration testing for the methodology behind it.
How is this checklist structured around MASVS?
It follows the seven MASVS control groups and the three verification levels. The groups are Storage, Crypto, Auth, Network, Platform, Code quality, and Resilience. Every test below maps to one group so your report references a concrete control.
The levels tell you how far to push: MASVS-L1 is the security baseline every app should meet; MASVS-L2 adds defense-in-depth for apps handling sensitive data (banking, health); MASVS-R adds resilience against reverse engineering and tampering, relevant when the client enforces business rules or DRM. Scope the engagement to the right level before you start so you do not over-test a low-risk app or under-test a regulated one.
Mobile pentest checklist by MASVS category
Storage
- ✓No cleartext tokens/PII in SharedPreferences, plists, SQLite, or external storage
- ✓Keychain/Keystore used for secrets, not the binary
- ✓Sensitive data cleared on logout; no leaks in app backups or logs
Crypto
- ✓No hardcoded keys, ECB mode, or static IVs
- ✓Strong algorithms only (no MD5/SHA1 for security)
- ✓Keys generated and stored in Keystore/Keychain
Auth
- ✓Tokens scoped, expiring, and invalidated on logout
- ✓Biometric/local auth cannot be bypassed via Frida hook
- ✓No credentials cached in memory longer than needed
Network
- ✓TLS validated; no acceptance of attacker CA
- ✓Certificate pinning present and not defeated by stock objection/Frida
- ✓Cleartext (HTTP) traffic blocked
Platform
- ✓Exported components reviewed and probed with Drozer
- ✓Deeplinks/URL schemes validate input and authorization
- ✓WebView JS bridges and file access locked down
Code
- ✓Not debuggable; allowBackup disabled
- ✓No secrets logged
- ✓Third-party SDKs inventoried and their data flows reviewed
Resilience (MASVS-R)
- ✓Root/jailbreak detection resists Frida/objection bypass
- ✓Anti-debugging and emulator detection present
- ✓App integrity/signature checks in place
What goes in the storage and crypto checks?
Storage and crypto are where most exploitable findings appear, so test them first. The aim is simple: nothing sensitive in cleartext, and no broken or hardcoded cryptography.
For storage, pull the app's data directory after exercising every feature and grep it. On Android check SharedPreferences XML, SQLite databases, and external storage; on iOS check plists, NSUserDefaults, and the Keychain (dump it with objection). For crypto, decompile with jadx or Hopper and search for hardcoded keys, ECB mode, static IVs, weak hashes (MD5/SHA1), and use of insecure random. Confirm keys are backed by the Android Keystore or iOS Keychain, not bundled in the binary.
How do you test network and certificate pinning?
Route the app through Burp Suite or mitmproxy and confirm two things: TLS is correctly validated, and certificate pinning is present and not trivially bypassable. Install your CA cert, then watch whether traffic flows or the app refuses to connect.
If traffic flows with your CA trusted, pinning is missing (an L2 gap). If it blocks, attempt a bypass with objection (android sslpinning disable) or a custom Frida script hooking the TrustManager, OkHttp, or NSURLSession layer. A pin that any off-the-shelf Frida script defeats provides little real protection. When the app ignores the proxy entirely or uses raw sockets, switch to forced redirection, covered in intercepting proxy-unaware app traffic.
Strobes insight
Treat any certificate pin that a default objection one-liner defeats as effectively absent. Real pinning forces an attacker to patch the binary, not run a stock script.
Platform checks examine how the app talks to the OS and other apps; code checks examine injection and debug hygiene. On Android, dump the manifest and review every exported activity, service, receiver, and content provider, then probe them with Drozer. Test deeplinks and intents for parameter injection and unauthorized actions.
- Review WebViews for
setJavaScriptEnabled, addJavascriptInterface exposure, and file:// access. - On iOS, test custom URL schemes and universal links for the same unauthorized-action issues.
- Check for debuggable builds, verbose logging of secrets, and exposed backup flags (
android:allowBackup). - Inventory third-party SDKs and their data flows. SDK behavior is a test area of its own, covered in our mobile SDK security testing methodology.
When do resilience checks matter?
Resilience checks (MASVS-R) matter when the client itself enforces something attackers want to defeat: licensing, anti-fraud, or business logic that the server cannot fully re-validate. They are not required for every app, so confirm scope before spending time here.
Test root/jailbreak detection by running on a Magisk-rooted or jailbroken device and trying to bypass the check with objection or a Frida hook. A single hook that flips the detection result means the control is weak. Do the same for anti-debugging, emulator detection, and integrity/signature checks. For Android specifically, our guide on root detection and Android security shows what real versus cargo-cult detection looks like. The goal is not perfect protection (it does not exist) but enough friction to be meaningful.
Frequently asked questions
What is the difference between MASVS-L1, L2, and R?
L1 is the baseline every app should meet. L2 adds defense-in-depth for apps handling sensitive data such as banking or health. R adds resilience against reverse engineering and tampering (anti-debug, anti-instrumentation, integrity checks) for apps where the client enforces protections like DRM or anti-fraud. Scope an engagement to the level that matches the app's risk.
Which mobile pentest checks find the most issues?
Insecure local storage is the top source of exploitable findings, followed by missing or weak certificate pinning, and exported components or unvalidated deeplinks. These three categories account for a large share of real-world mobile breaches, so test storage, network, and platform interaction first.
Do I need a rooted or jailbroken device for the checklist?
For the dynamic checks (storage dumps, pinning bypass, runtime hooking, resilience testing), yes. Root via Magisk on Android or a jailbreak on iOS lets you run Frida server and read protected directories. Static checks with MobSF, jadx, and apktool run without a device.
How do you test SSL certificate pinning?
Proxy the app through Burp Suite or mitmproxy with your CA installed. If the app blocks traffic, attempt a bypass using objection's sslpinning disable command or a Frida script hooking the TrustManager, OkHttp, or NSURLSession. If a stock script defeats it, the pinning is weak. If traffic flows immediately, pinning is missing entirely.
Is resilience testing always required?
No. MASVS-R applies to apps where the client enforces business rules an attacker would want to bypass, like licensing, gaming anti-cheat, or fraud controls. A simple content app handling no sensitive data usually only needs L1, sometimes L2. Confirm the target level during scoping.
What tools cover this checklist end to end?
MobSF for automated static triage, jadx and apktool for Android decompilation, Hopper or Ghidra for iOS binaries, Frida and objection for runtime instrumentation, Burp Suite or mitmproxy for traffic interception, and Drozer for Android IPC. Together they cover all seven MASVS categories.
Sources and references
L
Likhil Chekuri
Application Security Engineer, Strobes
Likhil Chekuri is an AppSec engineer at Strobes who has run hundreds of web, mobile, and cloud penetration tests for regulated industries.
