Mobile Application Penetration Testing: iOS and Android

A mobile pentest is an offensive audit against the app your organisation publishes on the App Store and Google Play (or distributes internally via MDM) and against the conversation that app keeps with its servers. The attack surface is not just the user's screen: it includes the installed binary, the data on disk, the keys in Keychain or Keystore, the URL schemes other apps invoke, the services exposed by broadcast on Android and the API serving the data. An attacker with a rooted phone, a modified AVD and half an afternoon has access to the same things your QA team sees, and to quite a lot more.

This guide covers what a modern mobile pentest audits, how iOS and Android differ from the offensive perspective, the most exploited bugs under the current OWASP MASVS, the bypasses no development team ever closes on the first try and how mobile auditing fits NIS2, DORA, PCI DSS and ISO 27001.

What a mobile pentest is

A mobile pentest is an authorised and scoped offensive exercise against the IPA or APK/AAB binary your company distributes, against the data that app stores on the device and against the backend endpoints it consumes. The scope goes from the app itself to the surrounding ecosystem: embedded third-party SDKs, network configurations (App Transport Security on iOS, Network Security Config on Android), hardcoded credentials, forced update logic, jailbreak/root detection mechanisms and the API serving sensitive data.

Unlike an automatic SAST scan with a tool like MobSF, a professional mobile pentest:

• Runs static analysis and dynamic instrumentation in parallel. Static extracts secrets, hidden endpoints, dependencies and abusive permissions. Dynamic hooks the app at runtime with Frida or Objection and manipulates its real behaviour.
• Audits the backend with the app as legitimate client. The app signs requests, adds tokens and applies certificate pinning; a traditional web pentest against the same domain doesn't catch the bugs that only emerge when the app behaves as the client.
• Tests every channel outside standard HTTP: deep links, universal links, push notifications, IPC (broadcast receivers, content providers, service intents on Android; URL schemes and XPC on iOS).
• Checks at-rest security on the device: where tokens end up after logout, what gets dumped to system logs, what travels to iCloud or Google Backup, what leaks in task-switcher screenshots.
• Verifies jailbreak/root detection and obfuscation properly, not as a compliance checkbox. If it takes 10 minutes to bypass detection with Frida and a public script, the control doesn't protect.

Typical duration varies with complexity: an app that only consumes a REST API and shows data gets covered in 5-7 working days; a fintech or health app with its own SDK, offline module, custom cryptography and RASP anti-fraud can demand 15-25 days and a team with specific iOS and Android profiles.

Why run a mobile app pentest

Three operational reasons that are moving mobile pentesting from "nice to have" to "required":

1. The binary is outside your perimeter. Once published on the App Store or Play, the app lives on a device you don't control. An attacker can decompress the IPA or APK, read resources, extract embedded keys and observe TLS traffic from inside the device. The WAF that protects your web doesn't apply.
2. Mobile apps concentrate personal and financial data. Banking, healthcare, identity, payment tokens, continuous geolocation, biometrics. The regulatory impact surface (GDPR, PSD2 SCA, mobile PCI DSS) is broader than for most equivalent web apps.
3. NIS2, DORA, PCI DSS v4.0 and ISO 27001:2022 explicitly cover mobile apps. PCI DSS 6.4.6 demands technical testing after significant changes in any code touching card data, including the mobile client. NIS2 article 21 requires demonstrated effectiveness of technical measures on essential services delivered through an app.

Done well, a mobile pentest delivers:

• Real inventory of embedded SDKs and the data each one sends to its provider (advertising, analytics, attribution).
• List of bugs with reproducible proof of concept: captured HTTP request, Frida script, filesystem capture.
• Recommendations prioritised by exploitation risk and fix effort, not by isolated CVSS severity.
• Auditable evidence for PCI DSS QSAs, NIS2 auditors or ISO 27001:2022 auditors.

iOS and Android: why they get audited differently

iOS and Android share bug patterns but their technical surface differs enough that a team auditing only one leaves things behind on the other.

iOS

Apple closes a lot of the environment: default app sandbox, mandatory distribution via App Store or enterprise MDM, forced code signing, ATS (App Transport Security) demanding TLS 1.2+ with recommended cert pinning, Keychain as secret store backed by the Secure Enclave in hardware.

That rigidity makes typical iOS bugs live in a different layer:

• Insecure storage outside Keychain. The app stores tokens in UserDefaults, in plain sandbox files or in unencrypted Core Data. A jailbroken device is enough to extract them.
• ATS disabled in exceptions. The Info.plist has NSAllowsArbitraryLoads or per-domain exceptions allowing plain HTTP. Any intermediary reads the traffic.
• Poorly validated universal links. The app opens any URL of the domain instead of validating the specific path, and an attacker invokes internal actions via link.
• Jailbreak detection bypass. The app uses a public library or trivial checks (presence of /Applications/Cydia.app) that get bypassed with Liberty Lite or Shadow.
• WKWebView with insecure JavaScript bridge. The app exposes native functions to JavaScript without origin validation and a MITM calls them with arbitrary arguments.
• Excessive logging to os_log or NSLog. Tokens, authorisation headers and API responses end up in iOS unified logs and get exfiltrated with a USB cable.

Android

Android is more open and the surface grows: APK signed with developer's key, granular permissions, IPC via Intents and Content Providers, common sideloading, version fragmentation keeping old patches in production, real root option accessible to the user.

Typical Android bugs:

• Insecure exported components. activities, services, broadcast receivers or content providers declared with android:exported="true" without permission, reachable from another malicious app installed on the same device.
• WebView with setJavaScriptEnabled(true) and addJavascriptInterface. RCE risk on old Android versions and data exfiltration on any version.
• Open backup. android:allowBackup="true" in AndroidManifest.xml allows extracting the full local database with adb backup from a connected device.
• Cleartext traffic allowed. android:usesCleartextTraffic="true" or a lax Network Security Config lets plain HTTP traffic out without the developer noticing.
• Deeplinks with android:autoVerify="false". Another app on the device registers the same intent filter, intercepts the OAuth callback and grabs the token.
• Weak root detection. File checks (/system/bin/su) that get bypassed with Magisk Hide; the app keeps working as if on a clean device.

Hybrid apps: React Native, Flutter, Cordova

Hybrids add a layer: the JavaScript bundle (RN, Cordova) or the compiled Dart snapshot (Flutter) travels in the binary and gets reverse engineered with relative ease. What to watch:

• Unminified JS bundle leaking endpoints, keys and full logic.
• Third-party plugins from the corresponding marketplace with excessive permissions or known vulnerabilities.
• JS-native bridge poorly exposed: a webview loads external content and calls native code through the bridge.

Flutter has the advantage of compiling Dart to native binary (more expensive to reverse) but strings and endpoints are still in there.

OWASP MASVS and MASTG: the industry standard

OWASP maintains two essential artefacts any serious mobile auditor follows:

• MASVS (Mobile Application Security Verification Standard). Defines controls grouped in 7 categories: architecture, storage, cryptography, authentication, communications, platform and integrity. Each control has levels L1 (minimum), L2 (apps with sensitive data) and MASVS-R (resistance to reverse engineering, only when the threat model justifies it).
• MASTG (Mobile Application Security Testing Guide). The technical guide that details how to test each MASVS control on iOS and Android with concrete tools (Frida, Objection, MobSF, Drozer, Radare2, Hopper).

A professional report maps each finding to a MASVS control and references the specific MASTG test. That's what a PCI or NIS2 auditor wants to see.

Most exploited bugs in audited mobile apps

80% of critical findings in mobile apps fall into this pattern:

1. Insecure storage of tokens and sensitive data. JWT tokens in plain UserDefaults/SharedPreferences, unencrypted SQLite files, cache snapshots left on disk on the task switcher.
2. Cert pinning absent or trivially bypassable. The app doesn't validate the backend certificate or uses a custom implementation that a five-line Frida script defeats.
3. Backend bugs only visible with the app as client. The app signs each request with an HMAC; reproducing that signature from Postman is complicated, so the backend has never been audited properly. Result: BOLA, mass assignment and broken business logic at will.
4. Logs with sensitive data. Authorisation headers, full response payloads and stacks with secrets show up in system logs reachable by other apps with log permissions (old Android) or via USB cable.
5. Deep links without state validation. The app processes a link without checking that the user is authenticated or that the flow is legitimate. An attacker sends the user to a link that fires a dangerous action.
6. Cosmetic root/jailbreak detection. Detects the modified device, shows a warning, but lets the app keep running. Good for the PCI checkbox, not for real defence.
7. WebViews with relaxed configuration. JavaScript enabled, file:// allowed, content:// allowed and native bridge exposed. Any XSS in the loaded content turns into native API access.
8. Third-party SDKs with abusive permissions. An analytics SDK requesting access to contacts or continuous location without the product team being aware of the real traffic it generates.

Technical bypasses the development team doesn't expect

Three categories that get executed in hours in real reports:

Cert pinning

The standard defence is pinning the backend cert to prevent MITM. Common bypasses:

• Frida + community script (frida-multiple-unpinning, objection). Hooks the app's TLS validation functions and always returns OK.
• APK repackaging with SmaliPatcher or Frida-gadget tooling to introduce the bypass without needing root.
• iOS with SSL Kill Switch 3 on a jailbroken device, or with a proxy that replaces the binary at runtime.

Pinning done well makes the matching dynamic and rotates certificates with server-driven config. Most pinning in production is a single hardcoded cert.

Root/jailbreak detection

Common techniques (presence of /system/bin/su, presence of Cydia, getprop ro.debuggable check, call to Runtime.exec) get enumerated and hooked in bulk. Magisk Hide for Android and Shadow for iOS are community-maintained tools that automate concealment.

Reasonable defence: combine several signals, use attestation with Google Play Integrity API or Apple DeviceCheck/AppAttest against a backend server that decides whether to allow the session, and degrade sensitive functionality (for example, no transfers) rather than killing the app.

Anti-debugging and RASP

Regulated apps (banking, healthcare) usually embed commercial RASP (Promon SHIELD, Talsec, Verimatrix). A professional pentesting team dedicates a fraction of the effort to evaluating resistance, but it's worth knowing that RASP raises the attacker's cost, it doesn't block them. Mobile CTFs have been demonstrating bypasses for every commercial product for years.

Methodology of a professional mobile pentest

What we apply at Secra and what any serious team follows (aligned with MASTG):

1. Technical onboarding: delivery of IPA/APK, test account credentials, architecture documentation, list of SDKs. If there's a dedicated backend, accesses for legitimate traffic.
2. Static analysis. Decompilation with jadx or apktool (Android) and class-dump/Hopper/Ghidra (iOS). MobSF as first automated pass. Extraction of strings, secrets, endpoints, dependencies.
3. Lab setup. Physical jailbroken/rooted device or emulator (AVD for Android, iOS simulator only for some tests). Burp Suite + custom cert or mitmproxy for intercepted traffic. Frida server running on the device.
4. Dynamic analysis. Full functional walkthrough of the app with traffic captured. Hooking with Objection to dump Keychain/SharedPreferences, read local SQLite and extract tokens.
5. Backend audit with the app as client. BOLA, mass assignment, business logic, rate limiting. Here it overlaps with a classical API pentest. More in API penetration testing.
6. IPC and deep link audit. On Android with Drozer enumerating exported components; on iOS analysing registered URL schemes and universal links.
7. Defence bypass. Cert pinning, root/jailbreak detection, RASP if applicable. Document the effort needed, not just the result.
8. Reporting and retest. Executive report, technical report with reproducible PoC and debrief with the development team. Retest when fixes are ready.

Mobile pentesting and compliance: NIS2, DORA, PCI DSS, ISO 27001

• PCI DSS v4.0 (6.4.6). Any significant change in code touching card data requires technical testing. If your mobile app processes payments directly, it's PCI scope and the pentest must cover it. Minimum annual frequency.
• NIS2 (article 21). Effectiveness of technical measures in essential services. If the service is delivered through a mobile app (banking, telco, healthcare), the mobile pentest is the effectiveness proof the competent authority expects to see. More in NIS2 in Spain: a compliance guide for 2026.
• DORA (article 25). Digital operational resilience testing. Significant financial entities must pentest their critical applications annually and include TLPT (TIBER-EU) every three years for apps considered critical. More in DORA compliance guide for financial entities 2026.
• ISO 27001:2022 (control 8.29). Security testing in the software lifecycle. The documented mobile audit covers this control for ISMSs that include apps in scope.

How to choose a mobile pentest provider

Five criteria that separate a serious team from one that just runs MobSF:

1. Explicit mapping to OWASP MASVS and MASTG. Each finding referenced to the specific control. If the report doesn't include it, the team hasn't read the standard.
2. Team with dedicated iOS and Android profiles. Matches the level of the client's team. A pentester only on Android misses details on Keychain, ATS, App Groups and entitlements.
3. Real dynamic instrumentation capability with Frida and Objection, not only static analysis with MobSF. Ask for it explicitly when evaluating proposals.
4. Joint backend audit with the app as client. Without that part, object-level authorisation bugs don't appear.
5. Reproducible PoC and retest included in the original scope.

Frequently asked questions

What's the difference between mobile pentesting and web pentesting?

Mobile pentesting covers three fronts: the binary installed on the device (which can be read, modified and reinstalled), data at rest on disk and in native stores like Keychain/Keystore, and communication with the backend (same as web pentesting, but with the app as legitimate client signing requests and applying pinning). A traditional web pentest on the same API misses the bugs that only emerge when the app acts as the client.

How long does a mobile pentest take?

Depends on scope. An app consuming a simple REST API and showing data gets covered in 5-7 working days. A fintech app with an offline module, custom cryptography, commercial RASP and own SDK can demand 15-25 days with dedicated iOS and Android profiles. For services under DORA or PCI with TLPT, scope extends several weeks.

Do you need source code to audit the app?

No, although it helps. A black-box pentest against the IPA or APK binary already uncovers most critical bugs: the decompiler returns readable code and dynamic analysis reaches almost everything. Source code access speeds up the audit and lets you review logic that's hard to reach dynamically, but it's not a prerequisite.

Why does the app "that can't be rooted" get rooted in pentest?

Because root or jailbreak detection usually relies on checks an attacker with Frida or Magisk Hide neutralises in minutes. The modern standard is not to trust the control to the device: use server-side attestation (Google Play Integrity, Apple AppAttest) so the backend decides whether the session is legitimate.

Do you also need to audit the backend if you already audited the web?

Yes. Mobile apps consume routes, parameters and flows the web frontend doesn't touch. The HMAC signature, custom headers and pinning mean those endpoints rarely show up in a traditional web pentest. BOLA, mass assignment and business logic bugs frequent in mobile backend don't get discovered without a manipulated legitimate mobile client.

When should you audit the app, before going to the store or after?

Before the first release and after any release with structural changes (auth refactor, integration of a new SDK, payment logic, offline module). For apps with recurring compliance (PCI, DORA, NIS2), minimum annual pentest and minor technical review per release.

Related resources

• What is a penetration test: the cluster pillar, with methodology and comparisons with red team and bug bounty.
• Web application penetration testing: the sibling discipline on web frontend. Shares part of the backend when there's an app and a web on the same API.
• API penetration testing: REST and GraphQL: the audit of the backend serving the app, with OWASP API Top 10 detailed.
• Root an Android AVD for Burp Suite pentesting: technical tutorial for the Android lab setup.
• OWASP Top 10 2025 business vulnerabilities: context of the web Top 10 applicable to the API the mobile app consumes.

Mobile pentesting at Secra

At Secra we cover iOS and Android pentesting with dedicated profiles per platform, MASVS/MASTG mapping in the report, instrumentation with Frida and Objection, joint backend audit with the app as client and retest included in the scope. If your organisation publishes regulated apps (banking, healthcare, public sector) or has PCI DSS, NIS2 or DORA compliance, get in touch through contact or check our web and mobile audit service.