Mobile Pentest Checklist — iOS and Android in 2026

Published May 19, 2026 · By AxVeil Mobile · 15 min read

Mobile pentesting in 2026 lives or dies on its alignment to OWASP MASVSand MASTG. MASVS is the "what", MASTG is the "how", and the combined coverage is what your auditor, your customer's security team, and your own engineers expect to see in the report. This checklist walks the seven MASVS control groups in test-execution order, with the tooling and the common pitfalls for both iOS and Android, then maps the findings back to severity for your remediation programme. For methodology context start with our mobile pentest methodologypost and scope using the scoping checklist.

Preflight — tooling and test devices

Before any test case fires, the lab needs to be ready. The reproducible baseline:

• iOS: at least one jailbroken device (palera1n on A11+, checkra1n on older). iOS version ≤ latest minus two. Build a second non-jailbroken device for resilience tests.
• Android: at least one rooted device (Magisk on Pixel) plus an emulator with Google APIs for reproducibility (avd, Android Studio, Genymotion).
• Static analysis: MobSF (latest), Semgrep mobile rules, Apktool / jadx for Android, class-dump / Hopper / Ghidra for iOS.
• Dynamic analysis: Frida (server + client), Objection, Burp Suite Pro with CA on device trust store, mitmproxy fallback.
• Build artefacts: an AAB / IPA per release channel (prod, staging) with debug symbols available under NDA.
• Test accounts: at least two per user role, two devices per account, and an admin role for vertical-privilege tests.

MASVS-by-MASVS test execution

MSTG-STORAGE — local data protection

• Enumerate all writable locations: /data/data/<pkg> (Android), app sandbox + Keychain + UserDefaults (iOS).
• Grep for credentials, JWTs, PII, and secrets in SharedPreferences, SQLite, plist files, Realm DBs.
• Verify Keychain access groups are scoped; kSecAttrAccessibleWhenUnlockedThisDeviceOnly for sensitive items.
• Android: confirm databases declared with EncryptedSharedPreferences or SQLCipher; no fallback to plain SharedPreferences on first launch.
• Confirm backups: Android android:allowBackup="false" for sensitive apps; iOS items marked NSURLIsExcludedFromBackupKey.
• Inspect logcat (Android) and Console.app (iOS) for sensitive data leakage.

# Android - pull app data after login
adb shell run-as com.example.app tar c . | tar xv
grep -r -E "(eyJ|sk_live|password|secret)" .

# iOS - dump UserDefaults
frida -U -n MyApp -e 'var d = ObjC.classes.NSUserDefaults.standardUserDefaults();
                       send(d.dictionaryRepresentation().toString());'

MSTG-CRYPTO — cryptography usage

• Identify every cryptographic call site (static analysis + Frida hook of CC_MD5, EVP_DigestUpdate, javax.crypto.*).
• Flag MD5/SHA-1 for security-critical purposes; ECB mode; hard-coded IVs; null IVs.
• Verify key generation uses SecureRandom (Android) / SecRandomCopyBytes (iOS), not java.util.Random / arc4random for crypto-grade randomness where post-2024 audits expect arc4random_uniform.
• Confirm KDFs use Argon2id, scrypt, or PBKDF2 with ≥ 600,000 iterations (NIST SP 800-63B-4 baseline).
• Hardware-backed keys: Android Keystore strongbox attestation, iOS Secure Enclave for biometric-gated keys.

MSTG-AUTH — authentication and session

• Re-test all backend authentication flows from the app (refresh token rotation, logout token invalidation, session fixation).
• Biometric flows: confirm a real biometric prompt is shown, that fallback to PIN is properly gated, and that the key inside Keystore / Secure Enclave is bound to biometric set membership (setUserAuthenticationParameters).
• OAuth / OIDC: PKCE used on every public client, no implicit flow, redirect URI registered with a custom scheme that the OS treats uniquely (universal links / app links preferred).
• MFA: token entered in-app is treated as second-factor, not just a re-auth.
• Account-recovery flows accessible from mobile must require the same evidence as web.

MSTG-NETWORK — transport security

• Verify TLS 1.2+ enforced; HSTS or equivalent app-level pin on the principal API host.
• Certificate pinning: pin to leaf or intermediate, never to a root CA. Confirm pinning enforced at the network layer (OkHttp CertificatePinner, URLSession evaluation, Network.framework tlsSec_protocol_set_verify_block).
• Test pinning bypass with Frida; document time-to-bypass as a finding when < 5 minutes.
• Verify network security config (Android) blocks cleartext to any domain in production.
• Inspect WebView traffic: do they share the same pin set? Does setMixedContentMode block insecure subresources?

# Frida script - bypass OkHttp pinning (Android)
Java.perform(function () {
  var CertPinner = Java.use('okhttp3.CertificatePinner');
  CertPinner.check.overload('java.lang.String',
    'java.util.List').implementation = function (a, b) {
      console.log('[bypass] OkHttp pin for ' + a);
      return;
  };
});

# Time-to-bypass < 5 min => P1 finding

MSTG-PLATFORM — platform interaction

• Android AndroidManifest.xml review: exported=true on activities, services, receivers, providers without proper permission gates? Custom permission protection levels?
• Deep links: every android:scheme / iOS universal link entry tested for parameter injection, host trust check, intent redirection.
• IPC: enumerate exported components; fuzz Intent extras with the drozer-style approach or Frida-driven Intent crafting.
• WebView: addJavascriptInterface usage limited; setAllowFileAccess / setAllowUniversalAccessFromFileURLs off.
• iOS app extensions: keychain access group restrictions correct; shared container reads not leaking PII.
• Clipboard: copy of sensitive data scrubbed on app background (iOS UIPasteboard expiry, Android clearPrimaryClip).
• Screen recording / screenshots blocked on sensitive screens (FLAG_SECURE; iOS blurEffect on resign).

MSTG-CODE — code quality and supply chain

• Dependency scan: gradle / SPM / CocoaPods lockfiles run through OSV / Trivy / Snyk; flag CVEs by EPSS percentile and KEV membership (see CVSS 3.1 vs 4.0).
• Detect known-vulnerable libraries with mobile-specific risk: outdated WebView wrappers, abandoned ad SDKs, hardcoded backend SDKs from acquisitions.
• Confirm release builds are minified / obfuscated; debug symbols stripped or stored privately.
• Verify ProGuard / R8 / Swift optimisation does not strip security-critical checks.

MSTG-RESILIENCE — anti-tampering (MASVS-R)

• Root / jailbreak detection: does the app degrade gracefully or false-confidence (claim "safe" while running on a jailbroken device)?
• Frida / debugger detection: try a known evasion (Frida-detect-bypass scripts) and measure how long the detection holds.
• Anti-debug, anti-emulator, anti-hook techniques: do they detect Magisk Hide, palera1n stealth, Corellium?
• Integrity: APK signature verification at runtime, iOS code signing identifier check, server-side attestation (Google Play Integrity, Apple DeviceCheck / App Attest).
• Critical flows protected by attestation (login, payment) - server rejects requests without a valid attestation token.

Severity model

Score every finding with CVSS 4.0 and add an EPSS percentile where a CVE is involved. Apply a platform multiplier:

• P1 (Critical): remote-exploitable on a stock device, no user interaction (deep-link RCE, intent injection to privileged component, hardcoded production secret).
• P2 (High): exploitable with one tap (universal link to sensitive action, missing biometric gate on payment confirm).
• P3 (Medium): requires a rooted / jailbroken device (most data-at-rest issues, pinning bypass leading to MITM with custom CA install).
• P4 (Low): requires physical possession + advanced reverse engineering, or only impacts the attacker's own data.

Reporting and re-test

A mobile pentest report should include the MASVS coverage matrix (which controls were tested, the verdict per control, evidence link). MASTG test case IDs in the per-finding write-up help engineering reproduce the issue without context-switching. Offer a free re-test inside 60 days; mobile re-tests are often shorter because the test bench is already calibrated to the build.

Tooling that helps with the broader programme: our pentest cost estimatorfor budgeting a dual-platform engagement, and the CVSS calculatorfor scoring. For a sector view, healthcareand BFSI apps will want MASVS L2 across the entire engagement.

FAQ

Further reading

• Mobile Pentest Methodology
• API Pentest Methodology
• How to Scope a Pentest
• Glossary: MASVS