🤖 HackTricks / iOS Pentesting Checklist

iOS Pentesting Checklist

Preparation

  • [ ] Read iOS Basics
  • [ ] Read iOS Basic Testing Operations to learn current extraction, installation, and filesystem access workflows
  • [ ] Prepare your environment reading iOS Testing Environment
  • [ ] If you are testing on iOS 16+, enable Developer Mode and decide if you need a simulator, a paired physical device (xcrun devicectl), or a jailbroken/rootless device
  • [ ] If a jailbreak isn't available, review iOS Pentesting without Jailbreak
  • [ ] Read all the sections of iOS Initial Analysis to learn common actions to pentest an iOS application
  • [ ] Extract entitlements early and review Associated Domains, App Groups, keychain access groups, extension points, get-task-allow, and unusual capabilities
  • [ ] Review Info.plist for CFBundleURLTypes, LSApplicationQueriesSchemes, NSAppTransportSecurity, WKAppBoundDomains, and .appex extension declarations

Data Storage

  • [ ] Plist files can be used to store sensitive information.
  • [ ] Core Data (SQLite database) can store sensitive information.
  • [ ] YapDatabases (SQLite database) can store sensitive information.
  • [ ] Firebase misconfiguration.
  • [ ] Realm databases can store sensitive information.
  • [ ] Couchbase Lite databases can store sensitive information.
  • [ ] Binary cookies can store sensitive information
  • [ ] Cache data can store sensitive information
  • [ ] Automatic snapshots can save visual sensitive information
  • [ ] Keychain is usually used to store sensitive information that can be left when reselling the phone.
  • [ ] If the app uses App Groups, inspect the shared container and shared preferences reachable by the main app, widgets, and share extensions
  • [ ] Review Data Protection / NSFileProtection classes in both the app container and any group container, especially files left as NSFileProtectionNone or NSFileProtectionCompleteUntilFirstUserAuthentication
  • [ ] Review Keychain item protections (kSecAttrAccessible*, SecAccessControl) and any keychain access groups; secrets intended to be device/biometry-bound should use restrictive flags such as ThisDeviceOnly / biometryCurrentSet
  • [ ] In summary, just check for sensitive information saved by the application in the filesystem

Keyboards

Logs

  • [ ] Check if sensitive information is being logged
  • [ ] Check unified logging and crash artifacts in addition to app-controlled logs, especially after login, token refresh, deep link handling, and WebView activity

Backups

  • [ ] Backups can be used to access sensitive information saved in the file system (check the initial point of this checklist)
  • [ ] Also, backups can be used to modify some configurations of the application, then restore the backup on the phone, and then as the modified configuration is loaded some (security) functionality may be bypassed
  • [ ] Verify whether secrets expected to be device-only or non-migratable survive backup / restore or device-to-device migration because the app uses a migratable Keychain class

Applications Memory

Broken Cryptography

Local Authentication

  • [ ] If a local authentication is used in the application, you should check how the authentication is working.
  • [ ] If it's using the Local Authentication Framework it could be easily bypassed
  • [ ] If it's using a function that can be dynamically bypassed you could create a custom Frida script
  • [ ] Check for LAContext reuse / touchIDAuthenticationAllowableReuseDuration so sensitive actions succeed because the device was recently unlocked instead of triggering a fresh biometric prompt
  • [ ] If keychain items are unlocked with biometrics, verify whether biometric enrollment changes invalidate them (biometryCurrentSet) or if they remain accessible unexpectedly

Sensitive Functionality Exposure Through IPC

  • Custom URI Handlers / Deeplinks / Custom Schemes
  • [ ] Check if the application is registering any protocol/scheme
  • [ ] Check if the application is registering to use any protocol/scheme
  • [ ] Check if the application expects to receive any kind of sensitive information from the custom scheme that can be intercepted by another application registering the same scheme
  • [ ] Check if the application isn't checking and sanitizing user input via the custom scheme and some vulnerability can be exploited
  • [ ] Check if the application exposes any sensitive action that can be called from anywhere via the custom scheme
  • [ ] If OAuth / SSO callbacks use custom schemes, test scheme hijacking with a malicious app and prefer claimed https / Universal Links for auth callbacks
  • Universal Links
  • [ ] Check if the application is registering any universal protocol/scheme
  • [ ] Check the apple-app-site-association file
  • [ ] Audit the AASA for wildcards / over-broad paths or components and sensitive or unpublished routes
  • [ ] Verify undefined routes that still match AASA rules return 404 and that wildcard subdomains are not over-trusted
  • [ ] Check if the application isn't checking and sanitizing user input via the universal link and some vulnerability can be exploited
  • [ ] Check if the application exposes any sensitive action that can be called from anywhere via the universal link
  • UIActivity Sharing
  • [ ] Check if the application can receive UIActivities and if it's possible to exploit any vulnerability with specially crafted activity
  • UIPasteboard
  • [ ] Check if the application is copying anything to the general pasteboard
  • [ ] Check if the application is using the data from the general pasteboard for anything
  • [ ] Monitor the pasteboard to see if any sensitive data is copied
  • App Extensions
  • [ ] Is the application using any extension?
  • [ ] Enumerate every .appex, inspect NSExtensionActivationRule, and map which App Group / shared container each extension can reach
  • WebViews
  • [ ] Check which kind of webviews are being used
  • [ ] Check the status of javaScriptEnabled, JavaScriptCanOpenWindowsAutomatically, hasOnlySecureContent
  • [ ] Check if the webview can access local files with the protocol file:// (allowFileAccessFromFileURLs, allowUniversalAccessFromFileURLs)
  • [ ] Check if JavaScript can access native methods (JSContext, postMessage)
  • [ ] Check if the app opted into WKAppBoundDomains / limitsNavigationsToAppBoundDomains when using hybrid content or privileged JS bridges
  • [ ] If WKScriptMessageHandler / postMessage bridges exist, confirm they validate the current URL/origin/frame before dispatching privileged native functionality
  • [ ] Check whether WKWebView.isInspectable / JSContext.isInspectable is enabled in production builds or can be flipped at runtime to inspect embedded JavaScript

Network Communication

  • [ ] Perform a MitM to the communication and search for web vulnerabilities.
  • [ ] Check if the hostname of the certificate is checked
  • [ ] Check/Bypass Certificate Pinning
  • [ ] Review NSAppTransportSecurity for NSAllowsArbitraryLoads, NSAllowsArbitraryLoadsInWebContent, NSAllowsLocalNetworking, per-domain NSExceptionDomains, and legacy NSTemporaryException* keys
  • [ ] If the app uses lower-level sockets, IP literals, or .local hosts, test those flows separately because ATS protections may not apply

Misc

References