Skip to main content

iOS Testing Methodology

Last Update: July 20, 2025

The mobile application penetration testing methodology consists of a hybrid approach using both automated and manual analysis. This approach leads to a comprehensive test of the enabled security controls implemented to protect the application data. All discovered findings are referenced using current industry standard categories from the OWASP Mobile Top 10, or the Common Weakness Enumeration (CWE). All mobile applications are tested using either a physical device or a virtual device which has been jailbroken or rooted, to allow unrestricted access to the application and its data.

Dynamic Application Security Testing (DAST) for mobile typically occurs when the application is in its running state. However, given the unique nature of mobile applications, there is also a component of testing that is focused on the static analysis of the files that make up the application, including the executable binary. All static analysis will occur from the compiled application, and is not a replacement or supplement for Static Application Security Testing (SAST) or Source Code Review (SCR) which should be performed outside of DAST.

When evaluating the security of a mobile application, there are three main areas where a vulnerability may be present; on the device, the network the device is on, or in the communications to the backend. For a comprehensive DAST test, all three of these areas should be tested using the general information below as a guide.

If the backend server is hosted at a third-party, then you must have written approvals from the vendor to perform penetration testing activities. If the vendor has monitoring enabled, it is possible that your communications could be considered malicious in nature which could cause legal or contractual issues. Testing should not begin until you have received written approval to perform the test.


iOS Application Testing

Information Gathering

Test CaseOWASPLocation
Decrypt application (if necessary)M1 / M8Device
Evaluate all proper binary protections are enabledM8Device
Examine all application defined permissionsM10Device
Collect all URL Schemes or Deep Links that the application definesM1Device
Identify all components of the application
- WebView’s
- Third party keyboards
- App Transport Security
- Libraries/Frameworks
N/ADevice
Minimum iOS version is 12.0 or greaterN/ADevice
Is jailbreak detection enabled in the appN/ADevice

Data Storage and Privacy

Test CaseOWASPLocation
System credentials or other sensitive data are not stored locally on the deviceM2Device
App does not store data outside of the app container or KeychainM2Device
No sensitive data is written to logsM2Device
No sensitive data is shared with third partiesM2Device
Keyboard cache is disabled on text inputs for sensitive data, such as password fieldsM2Device
Sensitive data is not shared or exposed through XPC mechanismsM2Device
Sensitive data is not exposed through the user interface of the app (masked)M2Device
Sensitive data is not included as part of a backup generated by iOSM2Device
The app removes any sensitive data from Views as the app is backgroundedM2Device
The app removes any sensitive data from memory when no longer necessary for the app to operate
Minimum iOS at 12.0 or newer requires a reboot for jailbreak
M2Device
No sensitive data is stored locally on the device in Property List files or SQLite databases
- If data is stored locally, it should be stored in an encrypted SQLite database using SQLCipher
- This should only persist while the user is actively logged in
- All sensitive data should be removed following an excessive number of failed logins
M2Device
Pasteboard leakageM2Device

Cryptography

Test CaseOWASPLocation
The app does not use hardcoded cryptography keysM5Device
The app uses proven implementations of cryptography (i.e., CCCrypt)M5Device
The app does not re-use the same cryptographic key for multiple purposesM5Device
All random values are generated from a secure random number generatorM5Device
The app does not store the cryptographic keys locally on the deviceM5Device

Authentication and Session Management

Test CaseOWASPLocation
If the app requires a login, ensure the app performs the authentication at the remote endpoint and not on the deviceM4 / M6Server Communications
The remote endpoint uses randomly generated session identifiers to authenticate app requests without re-sending user credentialsM4 / M6Server Communications
If Bearer tokens are used, the server provides a signed token from a secure algorithmM4 / M6Server Communications
The remote endpoint terminates the session when the user logs outM4 / M6Server Communications
A complex password policy is in use and enforced at the remote endpointM4 / M6Server Communications
The remote endpoint should protect the app from submitting credentials an excessive number of times (i.e., brute-force credentials)M4 / M6Server Communications
Sessions are invalidated at the endpoint after a predefined period of inactivityM4 / M6Server Communications
If biometrics are used for authentication, validate that the process unlocks the Keychain to access the credentialsM4 / M6Device
Biometrics use the device built-in functions of excessive failuresM4 / M6Device
Any sensitive transactions require two factor authenticationM4 / M6Server Communications
Application does not collect device specific information such as UDIDM4 / M6Device

Network Communication

Test CaseOWASPLocation
App transport security (ATS) is setup correctlyM3Device
Data in motion is encrypted using the latest TLS, and that the secure channel is used consistently throughout the appM3Server Communications
The app verifies the X.509 certificate of the remote endpoint when the secure channel is used (i.e., Certificate pinning)M3Server Communications
Only certificates from a trusted Certificate Authority (CA) are acceptedM3Device
The app does not rely on insecure communications (e-mail or SMS) for critical operations, such as enrollments or account recoveryM3Device

Platform Interaction

Test CaseOWASPLocation
The app only requests the permissions required for the app to runM1 / M10Device
User input is validated and sanitized (if required) on the server side
- Views
- XPC
- Custom URL’s
M7Device
App does not export sensitive functionality via URL Schemes or Deep LinksM1Device
If the app makes use of Cross Process Communication (XPC), proper protections are in placeM1 / M3Device
JavaScript is disabled in WebView’s unless specifically requiredM7 / M1Device
WebView’s are configured to use only secure protocols (https) and disallows dangerous protocols such as file:\, tel:, and app-id:M7 / M1Device
WebView’s only render JavaScript (when needed) inside the app containerM7 / M1Device
Object deserialization is handled properlyM7 / M8Device
WebView’s that store a cache of loaded resources should be cleared when the WebView is destroyedM2 / M7Device
Verify that the app does not allow the use of third-party keyboardsM7 / M1Device

Code Quality and Build Settings

Test CaseOWASPLocation
The app is properly signed with a valid certificateM7 / M8Device
The app is built in release mode, and is not a debug buildM7 / M8Device
Debugging symbols have been stripped from the executableM7 / M8Device
The app does not log any verbose errors or debugging messagesM7 / M8Device
Third-party components are identified and checked for known vulnerabilitiesM7 / M8Device
The app catches and handles all possible exceptionsM7 / M8Device
Toolchain security features are enabled such as stack protection, position independent code, and automatic reference countingM7 / M8Device

Reverse Engineering

Test CaseOWASPLocation
Jailbreak detectionM9Device
Bypass certificate pinning (if there is no DAST build available)M9Device
Anti-Frida checksM9Device
Anti-debugging checksM9Device
Decrypt SQLCipher databasesM9Device