iOS Pentest with MASVS in 2026: The Practitioner Workflow

Last updated: May 18, 2026

iOS pentesting in 2026 is more constrained than Android — Apple’s hardware-rooted security model leaves a smaller attack surface — but the fundamentals still apply. Insecure local storage, weak inter-process communication, broken authentication, exposed deep links, certificate-pinning bypass on jailbroken devices. This article covers the OWASP MASVS-aligned iOS pentest workflow, the specific tools (Frida, Objection, Hopper, Ghidra) that work, and the controls that actually matter for Indian mobile-banking-class apps.

The MASVS framework

OWASP Mobile Application Security Verification Standard (MASVS) defines security requirements across 7 control families:

• V1 — Architecture, Design, Threat Modeling
• V2 — Data Storage and Privacy
• V3 — Cryptography
• V4 — Authentication and Session Management
• V5 — Network Communication
• V6 — Platform Interaction
• V7 — Code Quality and Build Settings
• V8 — Resilience (anti-tampering)

For consumer apps, MASVS-L1 is the floor. For banking / health / payment apps, MASVS-L2 + V8 resilience is the bar. Indian RBI mobile-banking guidelines effectively map to MASVS-L2.

Lab setup for iOS

You need a jailbroken iOS device (typically an older iPhone — iPhone X to 12 with Dopamine or Palera1n jailbreak in 2026) or the corellium emulator (commercial). Pure-emulator iOS pentesting via simulator is constrained because Simulator does not run actual ARM iOS code — you cannot fully replicate runtime behaviour.

Tools to install via Cydia / Sileo:

• Frida server — runtime instrumentation
• Objection — runtime mobile exploration toolkit
• Filza — file manager with root access
• SSH — shell access
• Cycript / Frida-ios-dump — extract decrypted IPA from device

The workflow

Step 1: Extract the IPA

App Store apps are encrypted (FairPlay DRM). Use frida-ios-dump on the jailbroken device to extract the decrypted IPA. From your laptop:

git clone https://github.com/AloneMonkey/frida-ios-dump
./dump.py com.target.app -o target-decrypted.ipa

Step 2: Static analysis

Open the IPA in Hopper or Ghidra (free). Look for:

• Hardcoded API keys, secrets, internal URLs (strings target-binary | grep -E "key|secret|token")
• Disabled debug logs that print sensitive data
• Custom crypto implementations (almost always broken)
• Authentication bypass paths
• Insecure storage flags (NSFileProtectionNone)

Step 3: Insecure local storage (V2)

Common findings:

• NSUserDefaults containing tokens, PII, secrets — readable by Filza
• Plist files in app’s Documents directory with sensitive data
• Cache directory containing screenshots of sensitive views
• Keychain items without kSecAttrAccessibleWhenUnlocked protection
• SQLite databases unencrypted

Browse /var/mobile/Containers/Data/Application/<UUID>/ on the device with Filza or SSH.

Step 4: Network analysis (V5)

Set Burp as proxy on the device (Settings → Wi-Fi → Configure Proxy). Install Burp’s CA certificate (Settings → General → VPN & Device Management → trust profile, then Settings → General → About → Certificate Trust Settings).

For pinning bypass, use Objection:

objection -g com.target.app explore
ios sslpinning disable

This hooks NSURLSession, AFNetworking, and TrustKit pinning.

Step 5: Runtime hooking (V4, V6)

Use Frida to hook methods. From Objection:

ios hooking list classes
ios hooking list class_methods AppDelegate
ios hooking watch class AppDelegate
ios hooking watch method '-[AppDelegate authenticateUser:]' --dump-args --dump-return

Identify authentication functions, business-logic checks, jailbreak-detection routines. Hook to bypass.

Step 6: URL scheme and Universal Link abuse (V6)

iOS apps register URL schemes (custom://) and Universal Links (https://). Misconfigured schemes can:

• Trigger sensitive actions without authentication
• Open WebViews with attacker-controlled content
• Pass parameters that the app does not validate

Find registered schemes in Info.plist; test each by sending crafted URLs.

The 8 MASVS-L2 controls Indian apps fail most

From recent banking-class app audits:

1. V2.1 — sensitive data in NSUserDefaults / unprotected plists
2. V3.4 — custom crypto (often AES-ECB, hardcoded IV)
3. V4.1 — biometric prompts that don’t actually gate cryptographic operations
4. V5.4 — pinning configured but not enforced for all endpoints
5. V6.1 — exported URL schemes without parameter validation
6. V6.6 — WebView with javaScriptEnabled and unsafe URL loading
7. V7.5 — debug builds shipped to TestFlight or App Store
8. V8.1 — jailbreak detection trivial to bypass with Liberty Lite or Frida

Detection and resilience (V8)

For sensitive apps:

• Multiple-layered jailbreak detection — at least 5 distinct checks
• Frida / Objection detection — look for known signature classes, port scanning, anti-debug
• SSL pinning enforced for every endpoint, including third-party SDKs
• Sensitive operations gated by Secure Enclave (kSecAttrAccessControl with biometry)
• Code obfuscation with anti-tamper checks at runtime
• App Attest API for server-side device-integrity verification

How to find your next iOS bug

• Run Objection’s enumeration commands; ios keychain dump, ios cookies get, ios plist cat all surface stored secrets quickly.
• Decompile binary; search for NSLog, print, os_log — debug output often leaks PII in production.
• Test every URL scheme registered in Info.plist with crafted payloads.
• Check WebView usage; any WKWebView with javaScriptEnabled + non-allowlist URL loading is candidate for XSS / RCE.

Compliance angle

• RBI mobile banking — MASVS-L2 + V8 resilience is the de-facto bar.
• OWASP MASVS — directly applicable.
• DPDP §8(5) — apps storing personal data must protect it on-device.

The takeaway

iOS pentesting in 2026 is methodical: jailbroken device, Frida + Objection, MASVS checklist. The findings are predictable — V2 storage, V3 crypto, V8 resilience are the recurring categories. The defender’s job is to ship apps that pass MASVS-L2, with continuous adversarial testing each release. Apps shipped without an iOS pentest in the last year are statistically likely to have at least one MASVS-L1 violation; do not be surprised by your first report.

Related engagement → How we ran a mobile + API security review for a BFSI client