Swift iOS penetration testing: What we test in native iOS apps

Akande Simpa Lead Security Engineer & Cofounder, Simpa Labs CEH (Certified Ethical Hacker)

What a Swift iOS pentest covers

Our iOS penetration tests are structured around the four attack surfaces that produce real findings in production apps: local data storage, network communication, binary integrity, and API authorization. We do not run automated vulnerability scanners and call it a pentest. Every test is conducted manually on a jailbroken device using dynamic instrumentation tools.

1. Keychain and local storage analysis

The iOS Keychain is the correct location to store authentication tokens, certificates, and encryption keys. We verify that your app uses the Keychain with appropriate accessibility flags. The most common finding is using kSecAttrAccessibleAlways or kSecAttrAccessibleAfterFirstUnlock when kSecAttrAccessibleWhenUnlockedThisDeviceOnly is the appropriate scope for sensitive credentials.

Beyond the Keychain, we inspect every data store the app writes to at runtime. Using objection, we pull the complete on-device file system of the app sandbox immediately after login and inspect:

• NSUserDefaults: Frequently used to cache user profile data, tier levels, or flags. If authentication tokens land here, they survive backups and are readable without jailbreak.
• SQLite databases: Checked for unencrypted transaction histories, BVN fragments, or session tokens stored as plaintext rows.
• Plist files and caches: HTTP response caches in Library/Caches frequently contain complete API response bodies including account balances and personal details.

2. App Transport Security (ATS) and certificate pinning

ATS enforces HTTPS for all network connections. We inspect the app's Info.plist for NSAllowsArbitraryLoads exceptions that developers add to resolve connectivity issues during testing and leave in production. Finding this key set to true means the app will make unencrypted HTTP connections and accept any TLS certificate, making interception trivial with a proxy on the same network.

We then test certificate pinning with real bypass attempts. We hook the SSL verification function at runtime using Frida to confirm that pinning is actually enforced, not just configured in code. Many apps configure pinning libraries correctly but fail to call the validation method on every network request, leaving certificate pinning as partial protection at best.

3. Binary analysis and entitlements review

We extract the compiled Mach-O binary from the IPA and run static analysis using Hopper Disassembler. The goals are to identify hardcoded secrets (API keys, internal endpoints, admin tokens), reconstruct authentication logic flows, and locate debug build artefacts left in production binaries.

We also extract the app's entitlements file and audit the declared capabilities. Excessive entitlements (like com.apple.security.network.server on a banking app) expose unexpected attack surfaces. We check for keychain access group sharing between apps from the same developer, which can allow a malicious companion app to read credentials from your banking app's Keychain partition.

4. Objective-C runtime hooks on Swift apps

Swift code that interacts with UIKit, Foundation, and system frameworks crosses into Objective-C runtime territory. Using Frida, we hook these Objective-C method dispatch points to intercept data in transit between your Swift business logic and the underlying OS APIs. This is how we validate that local authentication (Face ID / Touch ID) cannot be bypassed by hooking the LAContext evaluatePolicy result before your app reads it.

// Frida hook to intercept LAContext biometric evaluation result
var LAContext = ObjC.classes.LAContext;
var evaluatePolicy = LAContext["- evaluatePolicy:localizedReason:reply:"];

Interceptor.attach(evaluatePolicy.implementation, {
  onEnter: function(args) {
    // Swap the reply block to always return success = true
    var replyBlock = args[4];
    // Forces the app to believe biometric succeeded regardless of sensor result
  }
});

5. API authorization and business logic testing

The most valuable findings are not in the binary at all. They are in the API the app calls. After extracting the full traffic profile through a man-in-the-middle proxy, we replay and manipulate every authenticated request against your backend. We look for Broken Object Level Authorization (BOLA) vulnerabilities, parameter manipulation (changing accountId to access another user's data), and privilege escalation through endpoint chaining.

For Nigerian fintech apps, we also test the specific flows that carry regulatory risk: BVN lookup responses, NIP transfer confirmation binding, transaction reference replay, and webhook endpoint validation on the backend.

What you get at the end

At the end of the engagement you receive a written report with a severity-ranked list of all findings, complete reproduction steps for each vulnerability, and prioritised remediation guidance written for your engineering team. We also schedule a findings walkthrough call to ensure nothing is misunderstood. For Nigerian fintechs, the report is structured to satisfy CBN IT audit documentation requirements.

Related reading

Blog: iOS vs Android security comparison · Certificate pinning in mobile banking · Mobile app pentest checklist

Services: Penetration testing · API security testing