Mobile 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 Case | OWASP | Location |
|---|---|---|
| Decrypt application (if necessary) | M1 / M8 | Device |
| Evaluate all proper binary protections are enabled | M8 | Device |
| Examine all application defined permissions | M10 | Device |
| Collect all URL Schemes or Deep Links that the application defines | M1 | Device |
| Identify all components of the application - WebView’s - Third party keyboards - App Transport Security - Libraries/Frameworks | N/A | Device |
| Minimum iOS version is 12.0 or greater | N/A | Device |
| Is jailbreak detection enabled in the app | N/A | Device |
Data Storage and Privacy
| Test Case | OWASP | Location |
|---|---|---|
| System credentials or other sensitive data are not stored locally on the device | M2 | Device |
| App does not store data outside of the app container or Keychain | M2 | Device |
| No sensitive data is written to logs | M2 | Device |
| No sensitive data is shared with third parties | M2 | Device |
| Keyboard cache is disabled on text inputs for sensitive data, such as password fields | M2 | Device |
| Sensitive data is not shared or exposed through XPC mechanisms | M2 | Device |
| Sensitive data is not exposed through the user interface of the app (masked) | M2 | Device |
| Sensitive data is not included as part of a backup generated by iOS | M2 | Device |
| The app removes any sensitive data from Views as the app is backgrounded | M2 | Device |
| 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 | M2 | Device |
| 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 | M2 | Device |
| Pasteboard leakage | M2 | Device |
Cryptography
| Test Case | OWASP | Location |
|---|---|---|
| The app does not use hardcoded cryptography keys | M5 | Device |
| The app uses proven implementations of cryptography (i.e., CCCrypt) | M5 | Device |
| The app does not re-use the same cryptographic key for multiple purposes | M5 | Device |
| All random values are generated from a secure random number generator | M5 | Device |
| The app does not store the cryptographic keys locally on the device | M5 | Device |
Authentication and Session Management
| Test Case | OWASP | Location |
|---|---|---|
| If the app requires a login, ensure the app performs the authentication at the remote endpoint and not on the device | M4 / M6 | Server Communications |
| The remote endpoint uses randomly generated session identifiers to authenticate app requests without re-sending user credentials | M4 / M6 | Server Communications |
| If Bearer tokens are used, the server provides a signed token from a secure algorithm | M4 / M6 | Server Communications |
| The remote endpoint terminates the session when the user logs out | M4 / M6 | Server Communications |
| A complex password policy is in use and enforced at the remote endpoint | M4 / M6 | Server Communications |
| The remote endpoint should protect the app from submitting credentials an excessive number of times (i.e., brute-force credentials) | M4 / M6 | Server Communications |
| Sessions are invalidated at the endpoint after a predefined period of inactivity | M4 / M6 | Server Communications |
| If biometrics are used for authentication, validate that the process unlocks the Keychain to access the credentials | M4 / M6 | Device |
| Biometrics use the device built-in functions of excessive failures | M4 / M6 | Device |
| Any sensitive transactions require two factor authentication | M4 / M6 | Server Communications |
| Application does not collect device specific information such as UDID | M4 / M6 | Device |
Network Communication
| Test Case | OWASP | Location |
|---|---|---|
| App transport security (ATS) is setup correctly | M3 | Device |
| Data in motion is encrypted using the latest TLS, and that the secure channel is used consistently throughout the app | M3 | Server Communications |
| The app verifies the X.509 certificate of the remote endpoint when the secure channel is used (i.e., Certificate pinning) | M3 | Server Communications |
| Only certificates from a trusted Certificate Authority (CA) are accepted | M3 | Device |
| The app does not rely on insecure communications (e-mail or SMS) for critical operations, such as enrollments or account recovery | M3 | Device |
Platform Interaction
| Test Case | OWASP | Location |
|---|---|---|
| The app only requests the permissions required for the app to run | M1 / M10 | Device |
| User input is validated and sanitized (if required) on the server side - Views - XPC - Custom URL’s | M7 | Device |
| App does not export sensitive functionality via URL Schemes or Deep Links | M1 | Device |
| If the app makes use of Cross Process Communication (XPC), proper protections are in place | M1 / M3 | Device |
| JavaScript is disabled in WebView’s unless specifically required | M7 / M1 | Device |
| WebView’s are configured to use only secure protocols (https) and disallows dangerous protocols such as file:\, tel:, and app-id: | M7 / M1 | Device |
| WebView’s only render JavaScript (when needed) inside the app container | M7 / M1 | Device |
| Object deserialization is handled properly | M7 / M8 | Device |
| WebView’s that store a cache of loaded resources should be cleared when the WebView is destroyed | M2 / M7 | Device |
| Verify that the app does not allow the use of third-party keyboards | M7 / M1 | Device |
Code Quality and Build Settings
| Test Case | OWASP | Location |
|---|---|---|
| The app is properly signed with a valid certificate | M7 / M8 | Device |
| The app is built in release mode, and is not a debug build | M7 / M8 | Device |
| Debugging symbols have been stripped from the executable | M7 / M8 | Device |
| The app does not log any verbose errors or debugging messages | M7 / M8 | Device |
| Third-party components are identified and checked for known vulnerabilities | M7 / M8 | Device |
| The app catches and handles all possible exceptions | M7 / M8 | Device |
| Toolchain security features are enabled such as stack protection, position independent code, and automatic reference counting | M7 / M8 | Device |
Reverse Engineering
| Test Case | OWASP | Location |
|---|---|---|
| Jailbreak detection | M9 | Device |
| Bypass certificate pinning (if there is no DAST build available) | M9 | Device |
| Anti-Frida checks | M9 | Device |
| Anti-debugging checks | M9 | Device |
| Decrypt SQLCipher databases | M9 | Device |
Android App Testing
Information Gathering
| Test Case | OWASP | Location |
|---|---|---|
| Evaluate all proper binary protections are enabled Check for JNI libraries | M8 | Device |
| Examine all application defined permissions | M10 | Device |
| Collect all URL Schemes or Deep Links that the application defines | M1 | Device |
| Identify all components of the application - WebView’s - Third party keyboards - App Transport Security - Libraries/Frameworks | N/A | Device |
| Is root detection enabled in the app | N/A | Device |
Data Storage and Privacy
| Test Case | OWASP | Location |
|---|---|---|
| System credentials or other sensitive data are not stored locally on the device | M2 | Device |
| App does not store data outside of the app container or KeyStore | M2 | Device |
| No sensitive data is written to logs | M2 | Device |
| No sensitive data is shared with third parties | M2 | Device |
| Keyboard cache is disabled on text inputs for sensitive data, such as password fields | M2 | Device |
| Sensitive data is not shared or exposed through IPC mechanisms | M2 | Device |
| Sensitive data is not exposed through the user interface of the app (masked) | M2 | Device |
| Sensitive data is not included as part of a backup generated by Android | M2 | Device |
| The app removes any sensitive data from Activities as the app is backgrounded | M2 | Device |
| The app removes any sensitive data from memory when no longer necessary for the app to operate | M2 | Device |
| No sensitive data is stored locally on the device in XML 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 | M2 | Device |
| Pasteboard leakage | M2 | Device |
Cryptography
| Test Case | OWASP | Location |
|---|---|---|
| The app does not use hardcoded cryptography keys | M5 | Device |
| The app uses proven implementations of cryptography | M5 | Device |
| The app does not re-use the same cryptographic key for multiple purposes | M5 | Device |
| All random values are generated from a secure random number generator | M5 | Device |
| The app does not store the cryptographic keys locally on the device | M5 | Device |
Authentication and Session Management
| Test Case | OWASP | Location |
|---|---|---|
| If the app requires a login, ensure the app performs the authentication at the remote endpoint and not on the device | M4 / M6 | Server Communications |
| The remote endpoint uses randomly generated session identifiers to authenticate app requests without re-sending user credentials | M4 / M6 | Server Communications |
| If Bearer tokens are used, the server provides a signed token from a secure algorithm | M4 / M6 | Server Communications |
| The remote endpoint terminates the session when the user logs out | M4 / M6 | Server Communications |
| A complex password policy is in use and enforced at the remote endpoint | M4 / M6 | Server Communications |
| The remote endpoint should protect the app from submitting credentials an excessive number of times (i.e., brute-force credentials) | M4 / M6 | Server Communications |
| Sessions are invalidated at the endpoint after a predefined period of inactivity | M4 / M6 | Server Communications |
| If biometrics are used for authentication, validate that the process unlocks the Keychain to access the credentials | M4 / M6 | Device |
| Biometrics use the device built-in functions of excessive failures | M4 / M6 | Device |
| Any sensitive transactions require two factor authentication | M4 / M6 | Server Communications |
| Application does not collect device specific information such as device ID | M4 / M6 | Device |
Network Communication
| Test Case | OWASP | Location |
|---|---|---|
| Data in motion is encrypted using the latest TLS, and that the secure channel is used consistently throughout the app | M3 | Server Communications |
| The app verifies the X.509 certificate of the remote endpoint when the secure channel is used (i.e., Certificate pinning) | M3 | Server Communications |
| Only certificates from a trusted Certificate Authority (CA) are accepted | M3 | Device |
| The app does not rely on insecure communications (e-mail or SMS) for critical operations, such as enrollments or account recovery | M3 | Server Communications |
Platform Interaction
| Test Case | OWASP | Location |
|---|---|---|
| The app only requests the permissions required for the app to run | M1 / M10 | Device |
| User input is validated and sanitized (if required) on the server side - Activities - IPC - Custom URL’s | M7 | Device |
| App does not export sensitive functionality via URL Schemes or Deep Links | M1 | Device |
| If the app makes use of Cross Process Communication (XPC), proper protections are in place | M1 / M3 | Device |
| JavaScript is disabled in WebView’s unless specifically required | M7 / M1 | Device |
| WebView’s are configured to use only secure protocols (https) and disallows dangerous protocols such as file:\, tel:, and app-id: | M7 / M1 | Device |
| WebView’s only render JavaScript (when needed) inside the app container | M7 / M1 | Device |
| Object deserialization is handled properly | M7 / M8 | Device |
| WebView’s that store a cache of loaded resources should be cleared when the WebView is destroyed | M2 / M7 | Device |
| Verify that the app does not allow the use of third-party keyboards | M7 / M1 | Device |
Code Quality and Build Settings
| Test Case | OWASP | Location |
|---|---|---|
| The app is properly signed with a valid certificate | M7 / M8 | Device |
| The app is built in release mode, and is not “debuggable” | M7 / M8 | Device |
| Debugging symbols have been stripped from the executable | M7 / M8 | Device |
| The app does not log any verbose errors or debugging messages | M7 / M8 | Device |
| Third-party components are identified and checked for known vulnerabilities | M7 / M8 | Device |
| The app catches and handles all possible exceptions | M7 / M8 | Device |
| Toolchain security features are enabled such as stack protection, position independent code, and automatic reference counting | M7 / M8 | Device |
Reverse Engineering
| Test Case | OWASP | Location |
|---|---|---|
| Root detection | M9 | Device |
| Bypass certificate pinning (if there is no DAST build available) | M9 | Device |
| Anti-Frida checks | M9 | Device |
| Anti-debugging checks | M9 | Device |
| Decrypt SQLCipher databases | M9 | Device |
| Decode / Decompile the APK for (near) source code review | M9 / M8 | Device |
Mobile Guided End Point Testing
You must evaluate the communications from the mobile app to the backend server under normal conditions to determine which of the following items needs to be evaluated. For instance, if you cannot interact with the mobile app until you are authenticated, then you would not perform the items in the “Unauthenticated Testing” section.
Information Gathering
| Test Case | OWASP | Location |
|---|---|---|
| Mobile app should have certificate pinning enabled | A6 | Device |
| Intercepting proxy is used | N/A | Device |
| Enumerate the endpoint (web server, OS, etc.) | A3 | Server Communications |
| Enumerate HTTP methods | A6 | Server Communications |
| Attempt default credentials | A2 | Server Communications |
| Ensure transport layers are deployed and configured properly | A6 | Server Communications |
Unauthenticated Testing
| Test Case | OWASP | Location |
|---|---|---|
| Crawl end point website | N/A | Server Communications |
| Attempt to enumerate users | A6 | Server Communications |
| Ensure application employs input validation and takes appropriate action when necessary | A1 | Server Communications |
| Confirm allowed/disallowed characters for input | A6 | Server Communications |
| Enumerate for backup, configuration, test, or debugging files | A6 | Server Communications |
| Attempt Indirect Object Reference (IDOR) | A5 | Server Communications |
| Validate authentication and authorization is in place for sensitive transactions | A2 / A5 | Server Communications |
| Check that error messages are “custom” and do not leak information | A6 | Server Communications |
| Review HTML comments for data leakage | A6 | Server Communications |
| Test authentication functions | A2 | Server Communications |
| Forgot username function | A2 | Server Communications |
| Forgot password function | A2 | Server Communications |
Authentication / Authorization Testing
| Test Case | OWASP | Location |
|---|---|---|
| Crawl end point website | N/A | Server Communications |
| Attempt to enumerate users | A6 | Server Communications |
| Ensure application employs input validation and takes appropriate action when necessary | A1 | Server Communications |
| Confirm allowed/disallowed characters for input | A6 | Server Communications |
| Enumerate for backup, configuration, test, or debugging files | A6 | Server Communications |
| Attempt Indirect Object Reference (IDOR) | A5 | Server Communications |
| Validate authentication and authorization is in place for sensitive transactions | A2 / A5 | Server Communications |
| Check that error messages are “custom” and do not leak information | A6 | Server Communications |
| Review HTML comments for data leakage | A6 | Server Communications |
| Ensure cookies do not store information in clear text | A6 | Server Communications |
| Validate password change requires current password | A2 | Server Communications |
| Confirm that GET requests are not used to transmit sensitive or session data | A6 | Server Communications |
| Validate that GET requests cannot be swapped for POST requests | A6 | Server Communications |
| Search for and test “hidden” form elements | A5 | Server Communications |
| Validate that sensitive information requires authorization | A5 | Server Communications |
| Ensure login forms are sent over an encrypted TLS channel | A6 | Server Communications |
| Validate account protections (i.e., lockouts) | A5 | Server Communications |
Session Testing
| Test Case | OWASP | Location |
|---|---|---|
| Session tampering | A2 / A5 | Server Communications |
| Session tokens are changed following successful login (session fixation) | A2 / A5 | Server Communications |
| Session tokens are not reused | A2 / A5 | Server Communications |
| Session tokens are properly terminated on the server after use logs out | A2 / A5 | Server Communications |
| Session tokens have an appropriate idle timeout, and the token is invalidated when this timeout is reached | A2 / A5 | Server Communications |
| Confirm session tokens random | A2 / A5 | Server Communications |