Mobile App Penetration Testing: iOS & Android

Mobile application penetration testing is a specialized assessment targeting the attack surface unique to iOS and Android apps: binary analysis, local data storage, inter-process communication, and runtime behavior. The 2023 OWASP Mobile Application Security Verification Standard (MASVS) establishes that most mobile security failures occur in the client itself — insecure local storage, weak cryptography, broken certificate validation — not in server-side components that a web pentest would cover. A backend API assessment leaves all of these risks unexamined.

Standard web application testing tools and techniques do not transfer to mobile environments; both platforms require specialized tooling and distinct methodologies. Mobile apps are closely coupled to the API layer that requires its own dedicated penetration testing approach — a complete mobile engagement typically covers both surfaces.

This guide covers the OWASP Mobile Top 10 (2023 edition), the significant testing differences between iOS and Android platforms, the distinction between static and dynamic analysis, and the professional tooling that makes mobile assessment credible.

OWASP Mobile Top 10 (2023): Current Mobile Risk Landscape

OWASP released an updated Mobile Top 10 list in 2023, reflecting the evolved mobile threat landscape. These ten categories define what a professional mobile pentest must assess.

M1 — Improper Credential Usage

Hardcoded credentials in application source code, API keys embedded in mobile builds, passwords stored in plain text in local databases or SharedPreferences, and credentials transmitted in URL parameters rather than request headers. Mobile applications are frequently reverse-engineered by attackers using freely available tools — any credential embedded in the binary is effectively public after the application is distributed. Testing involves binary analysis and static inspection of configuration files, resource files, and compiled strings.

M2 — Inadequate Supply Chain Security

Third-party SDKs, advertising networks, analytics libraries, and open-source components integrated into mobile applications introduce transitive risk. A single compromised analytics SDK embedded in a financial application can exfiltrate session tokens to a third-party endpoint. Testing covers SDK inventory, reviewing SDK permissions against their stated purpose, and checking for known vulnerabilities in embedded libraries using the NVD.

M3 — Insecure Authentication/Authorization

Mobile-specific authentication failures include biometric authentication bypass (checking the local result without server-side verification), authorization decisions made client-side (in JavaScript or Swift/Kotlin code that can be patched at runtime), and persistent authentication tokens stored without adequate protection that survive device loss or theft.

M4 — Insufficient Input/Output Validation

Input validation failures in mobile clients: SQL injection through local SQLite databases, JavaScript injection in WebView components, path traversal in file operations, and insufficient validation of data received from server-side APIs before rendering. WebView-based applications (hybrid apps built with Cordova, Ionic, or React Native using WebView) are particularly exposed — JavaScript Bridge configurations that expose native device functionality to web content are high-value attack targets.

M5 — Insecure Communication

Certificate validation failures are the most critical: applications that accept all TLS certificates without validation (disabling the certificate chain check or the hostname verification check) are trivially MitM-attacked. Custom certificate pinning implementations that are incorrectly coded, pinning the wrong values (leaf certificate hash that changes on each renewal rather than the CA or SPKI pin), or that lack a fallback pinning strategy are common findings.

M6 — Inadequate Privacy Controls

Applications collecting more device data than their stated purpose requires, transmitting user identifiers (IMEI, advertising ID, phone number) to analytics endpoints without disclosure, retaining location data beyond the consent scope, and failing to purge user data on account deletion. Testing maps data flows from the application to external endpoints and compares them against the privacy policy and consent disclosures.

M7 — Insufficient Binary Protections

Applications without obfuscation, integrity checking, or anti-tampering measures are straightforward to analyze and modify. Attackers can patch the binary to bypass license checks, remove security controls, or modify analytics identifiers. Testing evaluates the presence and effectiveness of obfuscation (ProGuard/R8 on Android, name mangling on iOS), root/jailbreak detection, and application integrity checking.

M8 — Security Misconfiguration

Android-specific: AndroidManifest.xml misconfiguration exposing exported Activities, Content Providers, or BroadcastReceivers to other applications without permission requirements; debug flags (android:debuggable="true") left enabled in production builds; network security configuration permitting cleartext traffic.

iOS-specific: App Transport Security (ATS) exemptions that allow cleartext HTTP connections; overly broad URL scheme registrations that allow other applications to deep-link into sensitive application states without authentication.

M9 — Insecure Data Storage

The most consistently discovered mobile vulnerability category. Common findings include:

Sensitive data (tokens, PII, API keys) stored in plain text in SharedPreferences (Android) or NSUserDefaults (iOS)
Unencrypted SQLite databases stored in application data directories
Sensitive data written to system log files accessible to other applications on rooted/jailbroken devices
Sensitive data cached by the operating system in screenshots taken when the application moves to the background
Keychain entries on iOS without appropriate accessibility attributes, accessible when the device is locked

M10 — Insufficient Cryptography

Use of deprecated or insecure algorithms (MD5, SHA-1, DES, RC4), static initialization vectors, insufficient key sizes, and incorrect cryptographic mode usage (ECB mode for symmetric encryption, which reveals patterns in the plaintext). Testing covers both static analysis of cryptographic API usage and dynamic analysis of encrypted values to identify structural weaknesses.

iOS vs. Android Testing: Platform Differences That Matter

iOS Testing Environment Requirements

Jailbroken device or simulator with security bypass — most dynamic analysis on iOS requires a jailbroken device with Cydia or a similar package manager to install testing tools. Alternatively, a corellium virtual device provides a controlled testing environment without requiring a physical jailbreak.
IPA file access — Apple's code signing requirements mean that IPA files from the App Store are encrypted and cannot be statically analyzed without decryption. Testers typically work with a development build (IPA with debugging enabled) provided by the client, or decrypt the binary from a jailbroken device.
Keychain analysis — iOS Keychain is the security-critical credential storage location; testing evaluates keychain item accessibility attributes and verifies that sensitive items are protected appropriately against backup extraction and device-unlocked access.
ATS (App Transport Security) — iOS enforces TLS requirements at the OS level; ATS exceptions in the application's Info.plist are explicitly tested.

Android Testing Environment Requirements

Rooted device or emulator — root access is required for many dynamic analysis techniques, including file system inspection of /data/data/ directories and hooking with Frida. Android emulators (AVD) can be run in rooted configuration for testing.
APK access — Android APK files are not encrypted at distribution time and can be decompiled without device access, making static analysis straightforward.
Network security configuration — Android 7.0+ ignores user-installed CA certificates by default; testing certificate pinning bypass requires installing a custom CA at the system trust store level (requires root) or working with a debug build that includes the test CA.
Content provider and intent analysis — Android's inter-process communication model (Intents, Content Providers) creates attack surface unique to the platform; exported components without proper permission requirements are explicitly tested.

Static Analysis vs. Dynamic Analysis

Static Analysis (Reverse Engineering and Code Review)

Static analysis examines the application binary without executing it:

Decompilation — Android APKs are decompiled with apktool (smali bytecode) and jadx (Java source reconstruction). iOS binaries are disassembled with Ghidra, IDA Pro, or Hopper.
String extraction — automated search for hardcoded API keys, credentials, URLs, and cryptographic material in decompiled source code and resource files
Configuration file review — AndroidManifest.xml, Info.plist, network security configuration files, and any bundled configuration JSON or property files
Third-party library inventory — identifying embedded SDKs and comparing against known-vulnerable versions

Tool: MobSF (Mobile Security Framework) — an open-source static and dynamic analysis framework that processes both APK and IPA files, producing an automated report covering manifest analysis, permission assessment, hardcoded secret detection, and known-vulnerable dependency identification. MobSF accelerates the static analysis phase significantly but does not replace manual review of flagged components.

Dynamic Analysis (Traffic Interception and Runtime Manipulation)

Dynamic analysis examines the application while it is executing:

Traffic interception — routing application traffic through Burp Suite Pro or OWASP ZAP to inspect and manipulate HTTP/HTTPS communications. Certificate pinning bypass is required before traffic interception is possible.
Runtime instrumentation with Frida — Frida is a dynamic instrumentation toolkit that injects a JavaScript engine into the running process, allowing testers to hook into arbitrary function calls, modify return values at runtime, bypass certificate pinning, bypass root/jailbreak detection, and extract cryptographic keys from memory during use.
Objection (Frida-based) — a runtime mobile exploration toolkit built on Frida that provides a command-line interface for common testing tasks: exploring the file system, dumping the Keychain, bypassing certificate pinning, disabling biometric controls, and listing loaded classes.
Runtime data inspection — inspecting local databases, cache files, and log entries generated by the application during normal use, including data written during operations that the static analysis suggested might be problematic.

Certificate Pinning Bypass

Certificate pinning is a security control that causes the application to accept only a specific certificate (or certificate chain) for a given server, preventing MitM attacks even if the attacker has a CA-trusted certificate. It is a valuable control, but it must be bypassed during testing to enable traffic interception.

Common bypass techniques:

Frida/Objection hook — hooking the certificate validation function at runtime to return true regardless of the certificate presented
Patching the APK — decompiling the APK with apktool, removing or modifying the pinning logic, recompiling and re-signing
Using a debug build — requesting a build variant from the client that does not implement pinning, or that trusts user-installed CAs
SSLUnpinning Frida script — a generic hooking script that targets common pinning implementations (OkHttp, TrustKit, Conscrypt) across multiple Android and iOS frameworks

OWASP MASTG (Mobile Application Security Testing Guide) — the testing companion to MASVS — documents specific bypass techniques for each major mobile framework and platform version. Qualified testers reference MASTG test cases to ensure complete coverage across platform-specific pinning implementations.

OWASP MASVS and MASTG: The Standard Reference

The OWASP Mobile Application Security Verification Standard (MASVS) defines security requirements for mobile applications across three levels: L1 (baseline), L2 (defense in depth), and R (resiliency against reverse engineering). The companion OWASP Mobile Application Security Testing Guide (MASTG) maps specific test cases to each MASVS control, providing the testing methodology equivalent of the WSTG for the mobile context.

A mobile application pentest that does not reference MASVS and MASTG is not applying a documented, repeatable methodology. These documents are the current industry standard for mobile security assessment and are recognized explicitly in the PCI Mobile Payment Acceptance Security Guidelines and the NIST Cybersecurity Framework. The OWASP web application penetration testing methodology provides the equivalent framework for the web layer, as many findings in mobile apps originate from the same backend services tested through the browser.

Real-World Use Case: Mobile App Pentest Finding

A fintech company launches an iOS application for peer-to-peer payments. The app passes internal QA and a static analysis scan before release. During a commissioned mobile application penetration test, the tester uncovers three distinct findings — all of them mobile-specific, and none visible in the web API penetration test the company had conducted six months earlier.

First, decompiling the app binary reveals a production API key hardcoded in a Swift configuration file. The key carries full account read and write permissions across the platform — any attacker who extracts it can read account balances, initiate transfers, and enumerate users without any further authentication.

Second, the tester intercepts application traffic using a custom certificate authority after confirming that certificate pinning is not implemented. In every API request — including requests made during unauthenticated browsing sessions — the application sends the user's device IMEI and full name. Neither field is necessary for any business logic, and neither disclosure is reflected in the app's privacy policy.

Third, the biometric authentication flow can be bypassed by hooking the LAContext.evaluatePolicy function using Frida. The application trusts the client-side result of the biometric check without any server-side verification step. An attacker with Frida installed on a jailbroken device can force the function to return a success result and access any account on the device.

At the time of the test, the application had 28,000 downloads. The hardcoded API key alone represented a full account takeover risk for every existing user.

Frequently Asked Questions

Does mobile app testing require the production app or a development build?

Both are useful, and the best engagements use both. A production build accurately represents what real users have installed — it may include last-minute changes, optimizations, or configurations that differ from development builds. However, production iOS builds are code-signed and distributed through the App Store in encrypted form, which complicates static analysis without a jailbroken device for decryption. A development build (typically an IPA with debugging enabled, distributed directly to the tester's device via TestFlight or ad-hoc distribution) is easier to analyze statically and often includes debug symbols that accelerate the assessment. For Android, APK files are not encrypted at distribution time and can be analyzed directly from any source. Providing both a production binary and a development build with debug symbols gives the tester maximum coverage without requiring workarounds.

How is iOS penetration testing different from Android testing?

The platforms differ in their security models, tooling requirements, and testing constraints. iOS enforces mandatory code signing, encrypts App Store binaries, and restricts inter-app communication to defined mechanisms (URL schemes, App Groups, and Share Extensions). Testing typically requires a jailbroken physical device or a virtual device platform like Corellium, and working with development builds avoids binary decryption complexity. Android has a more open architecture: APK files can be decompiled without device access, root is achievable on emulators and many physical devices, and Android's intent system creates an attack surface (exported Activities, Content Providers, BroadcastReceivers) that has no direct iOS equivalent. Android 7.0+ also requires system-level CA trust store access to intercept TLS traffic from applications that declare a network security configuration — a step that requires root. In practice, an Android assessment is often faster to instrument; an iOS assessment may require more setup but surfaces different vulnerability classes.

What is OWASP MASVS and how does it apply to mobile app testing?

OWASP MASVS (Mobile Application Security Verification Standard) is the industry-standard security requirements framework for mobile applications, maintained by the OWASP Foundation and updated in 2023. It defines security controls across categories including storage, cryptography, authentication, network communication, platform interaction, and code quality. MASVS organizes requirements into two levels: L1 covers baseline security controls applicable to all mobile apps, and L2 covers defense-in-depth controls for apps handling sensitive data (financial, health, or authentication credentials). A companion document, MASTG (Mobile Application Security Testing Guide), maps specific test cases to each MASVS control. Professional mobile penetration testers reference MASVS as their primary scope framework — if a provider cannot explain which MASVS controls their engagement covers, their methodology lacks a documented foundation.

How long does a mobile application penetration test typically take?

Scope and complexity drive timeline more than any single factor. A focused assessment of a single iOS or Android application with a defined feature set typically runs four to seven business days for a qualified tester. An assessment covering both iOS and Android versions of the same application, including the backend API that the app communicates with, typically requires eight to twelve business days. Applications with complex authentication flows, multiple user roles, extensive local data handling, or integrated third-party SDKs take longer. Organizations should be cautious about very short timelines — a one-day "mobile security review" almost certainly omits meaningful dynamic analysis and runtime instrumentation, which are the techniques that surface the most critical findings in mobile environments.

What should I do if my mobile app uses certificate pinning?

Certificate pinning is a valuable security control that should remain in production builds — it prevents real-world MitM attacks even when an attacker has a CA-trusted certificate. For testing purposes, testers need to bypass pinning temporarily to intercept and inspect application traffic. This is standard practice and does not require removing pinning from your production app. The recommended approach is to provide testers with a dedicated testing build that trusts a test certificate authority, or that has pinning disabled, delivered via a separate provisioning profile or build variant. Alternatively, your tester will use Frida-based hooking scripts (such as the SSL Unpinning script targeting OkHttp, TrustKit, or iOS's Security framework) to bypass pinning at runtime during the test session. Neither approach affects your production application. If your app implements pinning in an unusual or custom way, communicate this to your tester before the engagement starts — it affects their setup time.

One provider offering this combined mobile and API coverage is WhiteJaguars, with engagements structured around the OWASP MASVS framework in a single assessment.

Mobile App Penetration Testing: iOS & Android Security Guide