Mobile Application Penetration Testing Checklist

Why Mobile Apps Need Their Own Checklist

A web application checklist applied to a mobile app misses most of the issues that matter. The binary itself is part of the threat model: an attacker can decompile it, inspect strings, hook functions at runtime, modify the smali or Mach-O, and re-sign it. Sensitive data may sit on the device, on shared backups, or in OS-level paste buffers. The platform offers IPC mechanisms (intents on Android, URL schemes and universal links on iOS) that web apps simply do not have.

At the same time, the backend the mobile app calls is usually the larger risk. A hardcoded secret in the binary is bad; a backend API that trusts client-side flags is far worse. A complete mobile test treats the API as a first-class scope item, not an afterthought, and uses the same rigour described in the API security testing checklist and web application penetration testing checklist.

The OWASP MASVS organises mobile-specific risks into eight control groups: storage, cryptography, authentication, network, platform, code quality, resilience, and privacy. The sections below walk through each group with concrete things to test on iOS and Android.

1. Scoping and Pre-Test Preparation

Most weak mobile pentests start with weak scoping. Get this phase right and the rest of the engagement is straightforward.

• List the targets: iOS bundle identifier, Android package name, target build (release or debug), supported OS versions, and the build flavours in scope (production, staging, internal). A debug build with logging enabled is not the same target as a hardened release build.
• Request the right artifacts: a signed IPA for iOS, an APK or AAB plus the universal APK for Android, and where possible a non-hardened build that disables certificate pinning and root detection so testing is not gated on bypasses.
• Inventory the backend: base URLs for production and staging, OpenAPI or GraphQL schemas, third-party SDKs and analytics that send data outside the app, and any push notification or deep link infrastructure.
• Get test accounts: at least two accounts per role and at least two tenants for multi-tenant systems, plus test payment cards or equivalent if commerce flows are in scope.
• Verify domain ownership: any external testing against the backend should follow domain verification and recorded authorisation. SecPortal supports DNS TXT or meta tag verification before any external scan runs.
• Define the rules of engagement: testing windows, data handling for sensitive content found in responses, escalation contacts, what to do if real customer data appears, and whether re-signing or uploading test builds is allowed.

2. Test Environment and Tooling

Mobile testing needs a working lab before the methodology can run. Set this up once and reuse it across engagements.

Devices and emulators

• Jailbroken iOS device (or Corellium-style virtual device) running a supported iOS version
• Rooted Android device or emulator with Magisk and a recent supported API level
• Backup non-jailbroken or non-rooted device for production smoke tests
• Time set correctly and developer mode enabled where required

Static analysis

• jadx, apktool, and Ghidra for Android decompilation and resource inspection
• Hopper, Ghidra, or radare2 for iOS Mach-O analysis; class-dump for Objective-C runtime data
• MobSF for an automated first pass on both platforms
• Source SAST and SCA in CI when source is available; see the SAST vs SCA guide

Dynamic analysis

• Burp Suite or mitmproxy for traffic interception, with the proxy CA installed in the system trust store
• Frida and Objection for runtime instrumentation, hooking, and pinning bypass
• adb, idevicepair, and platform shells for file-system and process inspection
• iMazing or iTunes backups (iOS) and ADB pulls (Android) for offline data review

3. Local Data Storage (MASVS-STORAGE)

Most embarrassing mobile findings come from data left on the device. Walk every location an app can write to and verify what is there after meaningful actions (login, payment, message, document open).

• iOS sandbox: Documents, Library/Caches, Library/Preferences, tmp, plus shared App Groups containers
• Android sandbox: internal files, shared_prefs, databases, cache, and any external storage paths
• Keychain (iOS) and Keystore (Android) usage and accessibility flags (kSecAttrAccessibleWhenUnlockedThisDeviceOnly, EncryptedSharedPreferences)
• Logcat, NSLog, ASL, and crash reports for sensitive data
• Pasteboard and clipboard contents after sensitive flows
• WebView caches and cookies (WKWebView data store, CookieManager)
• App backups: allowBackup on Android, iCloud backups on iOS, exclusion flags for sensitive files
• Custom encrypted databases (SQLCipher, Realm with encryption key) and the way the key is derived and stored

Track each storage finding as its own template so it can be retested individually after fixes. SecPortal's findings management ships with templates for common mobile categories.

4. Cryptography (MASVS-CRYPTO)

Custom cryptography is rarely needed and rarely correct. Look for misuse of platform APIs and roll-your-own protocols.

• Use of broken or deprecated primitives (DES, RC4, MD5, SHA-1 for security purposes)
• Hardcoded keys, IVs, or salts in the binary
• ECB mode usage where confidentiality matters
• Key derivation that uses fast hashes instead of PBKDF2, scrypt, or Argon2
• Random values produced by non-CSPRNG sources
• Misuse of platform APIs (CommonCrypto, javax.crypto, BoringSSL) versus higher-level wrappers
• Custom signing or token formats that ship without a security review

5. Authentication and Session Management (MASVS-AUTH)

Most mobile authentication issues live on the backend, not the device. Test both sides.

Server-side

• Token issuance, expiry, refresh rotation, and revocation
• JWT signature verification, algorithm confusion, and missing audience checks
• Account lockout, rate limiting on login, MFA, and password reset
• OAuth flows: redirect URI validation, PKCE on public clients, state parameter
• Username enumeration via timing or message differences
• Session reuse across devices; revocation propagating to other sessions

Client-side

• Biometric authentication (Face ID, Touch ID, BiometricPrompt) bound to a Keychain or Keystore-protected secret, not a local boolean
• Local PIN or pattern: how it is stored, how many attempts are allowed, what happens after lockout
• Session timeout and what is shown in the app switcher (snapshot blur, sensitive data hiding)
• Logout: tokens cleared from memory, secure storage, and revoked server-side
• Decode any JWTs used by the app with the JWT decoder to verify scope, audience, and claim integrity

6. Network Communication (MASVS-NETWORK)

All sensitive traffic should be over TLS, validated, and ideally pinned. Test the failure modes, not just the happy path.

• Every endpoint reached from the app uses HTTPS (no http://, no allowsArbitraryLoads, no cleartext networkSecurityConfig)
• Server certificate validation is enabled and not overridden in custom TrustManagers or NSURLSession delegates
• Certificate or public-key pinning is implemented for high-value traffic
• Pinning is bypassable only with root or jailbreak (test with Frida, Objection, or a custom hook)
• TLS configuration on the server: protocol versions, cipher suites, HSTS, OCSP stapling. Verify with the SSL checker
• WebSocket and gRPC channels follow the same rules as REST traffic
• Third-party SDKs (analytics, crash reporting, ads) cannot be downgraded to HTTP and do not exfiltrate sensitive fields

7. Platform Interaction (MASVS-PLATFORM)

Each platform exposes IPC, deep links, and OS integrations that need careful review.

Android

• Exported activities, services, broadcast receivers, and content providers; verify intent filters and permission attributes
• Pending intent flags (FLAG_IMMUTABLE on modern targets), implicit intents that leak data
• Deep links and App Links: verify intent extras are sanitised, redirects are validated, and Android App Links are signed
• WebView configuration: setJavaScriptEnabled, setAllowFileAccess, addJavascriptInterface exposure
• Custom URL schemes versus verified App Links
• Permissions in the manifest match what the app actually uses

iOS

• URL schemes and Universal Links: scheme registration, associated domains entitlement, parameter validation
• App Extensions and shared App Groups: data classification of anything stored in shared containers
• Pasteboard usage: UIPasteboard items not marked local-only, expirable items missing expiry
• WKWebView configuration, allowsBackForwardNavigationGestures, JS message handlers
• Background modes, push handlers, and what they read or write
• Entitlements: keychain access groups, data protection class, App Transport Security exceptions

8. Code Quality and Server Logic

Once traffic is intercepted, the backend is in scope as a regular API. Apply the full authorisation, injection, business logic, and rate-limit testing from the API checklist. The mobile-specific angle is what the client sends and what the server blindly trusts.

• Replay every request after stripping or modifying the auth token, device ID, and tenant ID
• BOLA: replace object IDs in URLs and bodies with values belonging to other users or tenants
• BFLA: call admin or moderator endpoints with a regular user token
• BOPLA: send fields the client never sends (role, isAdmin, balance, status) in PUT and PATCH bodies
• Server trust of client signals such as device-side flag overrides, version numbers, locale, jailbreak flags
• Webhook and callback URLs: signature verification, replay protection
• File upload endpoints: type, size, content scanning, storage path predictability
• WebView-loaded URLs that come from the server: validate the origin and CSP

Pair this work with continuous backend coverage: SecPortal's authenticated scanning stores credentials with AES-256-GCM encryption and runs 17 modules behind login, so the same API surface is monitored between manual assessments.

9. Resilience and Anti-Tampering (MASVS-RESILIENCE)

Resilience controls slow attackers down rather than stop them. Score them as defence-in-depth and report what is missing relative to the threat model.

• Root and jailbreak detection: layered checks, not a single API call, and not blindly trusted by the server
• Debugger and emulator detection where the threat model justifies it
• Anti-hooking and anti-instrumentation against Frida and Substrate
• Code obfuscation level: identifier renaming, control-flow flattening, string encryption
• Repackaging and re-signing detection (signature checks, integrity hashes verified server-side)
• Anti-debug timing checks that do not break legitimate users on slow devices
• Sensitive-data wiping on tamper detection rather than crashing in a way that exposes state

10. Privacy and Data Minimisation (MASVS-PRIVACY)

• Permissions requested match what the app actually uses (location, contacts, microphone, photos, Bluetooth)
• Sensitive fields are masked in logs, analytics, and crash reports
• Third-party SDKs are inventoried; data shared with each is documented and justifiable
• App Privacy details (iOS) and Data Safety form (Android) reflect actual data collection
• Children-directed apps comply with platform rules and applicable regulation
• Data retention on the server has limits; deletion requests propagate to backups and analytics

11. Reporting and Remediation

A long list of findings without context is rarely actioned. Structure findings so engineering can pick them up and so auditors get the evidence they need.

• Map each finding to an OWASP MASVS control (and CWE where applicable)
• Score every finding with CVSS and verify with the CVSS calculator
• Include reproduction steps that name the device, OS version, build number, and exact request payload
• Attach short clips or screenshots for runtime issues that are hard to reproduce from text alone
• Provide a fix recommendation that names the layer (binary, platform configuration, backend) where it belongs
• Distinguish between defence-in-depth (resilience) and underlying authorisation or storage flaws
• Deliver findings in a portal that supports retest and persistent remediation status, not only a PDF

See the security assessment report template and how to write a pentest report for the full reporting structure.

12. Continuous Coverage Between Assessments

Manual mobile testing is high signal but slow, and mobile clients only change on release. The backend changes daily. Combine point-in-time mobile assessments with ongoing automated coverage so the API surface never drifts unmeasured.

• Add SAST and SCA into mobile CI to catch insecure patterns and vulnerable dependencies before release
• Run authenticated dynamic scans against the staging API on a recurring schedule using authenticated scanning
• Track headers, TLS, and exposure on every backend host with the external scanner
• Use continuous monitoring to detect regressions across releases and surface alerts on new findings
• Treat every CI failure as a finding so the audit trail is unified across mobile, backend, and infrastructure

For programme structure, see building a continuous security monitoring programme.

The Quick Checklist

A condensed version to use during the engagement.

1. Confirm bundle ID, package name, builds, OS versions, and backend environments in scope
2. Obtain at least two accounts per role and two tenants for authorisation testing
3. Stand up jailbroken iOS and rooted Android devices plus a non-jailbroken smoke-test device
4. Run MobSF and a manual review of the manifest, Info.plist, and entitlements
5. Walk every storage location (sandbox, Keychain, Keystore, backups, logs, clipboard) for sensitive data
6. Audit cryptography for primitive choice, key handling, IV reuse, and randomness
7. Test authentication on the server (tokens, lockout, MFA) and on the client (biometrics, session, snapshot)
8. Verify TLS, cert validation, and pinning; confirm pinning resists Frida and Objection on a rooted device
9. Review platform IPC: exported components, deep links, URL schemes, App Groups, WebView config
10. Apply BOLA, BFLA, and BOPLA tests to every API endpoint reached from the app
11. Score resilience controls (root/jailbreak detection, anti-hooking, repackaging, obfuscation) as defence-in-depth
12. Verify privacy: permissions, third-party SDKs, retention, App Privacy and Data Safety accuracy
13. Map findings to MASVS, score with CVSS, deliver in a portal with retest workflow
14. Set up continuous backend coverage with authenticated scans, external scans, and code scanning in CI

Frequently Asked Questions About Mobile Application Pentesting