deardaniel/secdata-raw huggingface dataset:
OWASP Mobile Application Security Testing Guide: MASTG TEST 0247

---
platform: android
title: References to APIs for Detecting Secure Screen Lock
id: MASTG-TEST-0247
apis: [KeyguardManager, BiometricManager#canAuthenticate]
type: [static]
weakness: MASWE-0008
best-practices: []
profiles: [L2]
knowledge: [MASTG-KNOW-0001]
---

## Overview

This test verifies whether an app is running on a device with a passcode set. Android apps can determine whether a secure [screen lock (such as PIN, or password)](https://support.google.com/android/answer/9079129) is enabled by using platform-provided APIs. Specifically, apps can utilize the [KeyguardManager](https://developer.android.com/reference/android/app/KeyguardManager) API, which provides the [isDeviceSecure()](https://developer.android.com/reference/android/app/KeyguardManager#isDeviceSecure()) and [isKeyguardSecure()](https://developer.android.com/reference/android/app/KeyguardManager#isKeyguardLocked()) methods to check if the device has a secure lock mechanism in place.

Additionally, apps can use the [BiometricManager#canAuthenticate(int)](https://developer.android.com/reference/android/hardware/biometrics/BiometricManager#canAuthenticate(int)) API to check whether biometric authentication is available and can be used. Since biometric authentication on Android requires a secure screen lock as a fallback, this method can serve as an alternative check when [KeyguardManager](https://developer.android.com/reference/android/app/KeyguardManager) is unavailable or restricted by device manufacturers.

If an app relies on biometrics for authentication, it should ensure that biometric authentication is enforced using the [BiometricPrompt](https://developer.android.com/reference/android/hardware/biometrics/BiometricPrompt) API or by requiring authentication for cryptographic key access via the **Android KeyStore System**. However, apps **cannot force** users to enable biometrics at the system level, only enforce its use within the app for accessing sensitive functionality.

## Steps

1. Use @MASTG-TOOL-0110 to identify the API that checks whether a secure screen lock has been set.

## Observation

The output should contain a list of locations where relevant APIs are used.

## Evaluation

The test fails if an app doesn't use any API to verify the secure screen lock presence.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0227

---
title: Debugging Enabled for WebViews
platform: android
id: MASTG-TEST-0227
type: [static]
weakness: MASWE-0067
best-practices: [MASTG-BEST-0008]
profiles: [R]
knowledge: [MASTG-KNOW-0028]
---

## Overview

The `WebView.setWebContentsDebuggingEnabled(true)` API enables debugging for **all** WebViews in the application. This feature can be useful during development, but introduces significant security risks if left enabled in production. When enabled, a connected PC can debug, eavesdrop, or modify communication within any WebView in the application. See the ["Android Documentation"](https://developer.chrome.com/docs/devtools/remote-debugging/webviews/#configure_webviews_for_debugging) for more details.

Note that this flag works independently of the `debuggable` attribute in the `AndroidManifest.xml` (see @MASTG-TEST-0226). Even if the app is not marked as debuggable, the WebViews can still be debugged by calling this API.

## Steps

1. Run @MASTG-TECH-0014 with a tool such as @MASTG-TOOL-0110 on the app binary and look for uses of:
    - `WebView.setWebContentsDebuggingEnabled` being set to `true`.
    - `ApplicationInfo.FLAG_DEBUGGABLE`.

## Observation

The output should list:

- All locations where `WebView.setWebContentsDebuggingEnabled` is called with `true` at runtime.
- Any references to `ApplicationInfo.FLAG_DEBUGGABLE`.

## Evaluation

The test case fails if `WebView.setWebContentsDebuggingEnabled(true)` is called unconditionally or in contexts where the `ApplicationInfo.FLAG_DEBUGGABLE` flag is not checked.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0265

---
platform: android
title: References to StrictMode APIs
id: MASTG-TEST-0265
type: [static]
weakness: MASWE-0094
best-practices: []
profiles: [R]
---

## Overview

This test checks whether the app uses `StrictMode`. While useful for developers to log policy violations such as disk I/O or network operations during development, it can expose sensitive implementation details in the logs that could be exploited by attackers.

## Steps

1. Run a static analysis (@MASTG-TECH-0014) tool to identify all instances of `StrictMode` APIs.

## Observation

The output should identify all instances of `StrictMode` usage in the app.

## Evaluation

The test fails if the app uses `StrictMode` APIs.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0249

---
platform: android
title: Runtime Use of Secure Screen Lock Detection APIs
id: MASTG-TEST-0249
apis: [KeyguardManager, BiometricManager#canAuthenticate]
type: [dynamic]
weakness: MASWE-0008
best-practices: []
profiles: [L2]
knowledge: [MASTG-KNOW-0001]
---

## Overview

This test is the dynamic counterpart to @MASTG-TEST-0247.

## Steps

1. Run a dynamic analysis tool like @MASTG-TOOL-0001 and look for uses of `KeyguardManager.isDeviceSecure` and `BiometricManager.canAuthenticate` APIs.

## Observation

The output should contain a list of locations where relevant APIs are used.

## Evaluation

The test fails if an app doesn't use any API to verify the secure screen lock presence.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0226

---
title: Debuggable Flag Enabled in the AndroidManifest
platform: android
id: MASTG-TEST-0226
type: [static]
weakness: MASWE-0067
best-practices: [MASTG-BEST-0007]
profiles: [R]
knowledge: [MASTG-KNOW-0007]
---

## Overview

This test case checks if the app has the `debuggable` flag ([`android:debuggable`](https://developer.android.com/guide/topics/manifest/application-element#debug)) set to `true` in the `AndroidManifest.xml`. When this flag is enabled, it allows the app to be debugged enabling attackers to inspect the app's internals, bypass security controls, or manipulate runtime behavior.

Although having the `debuggable` flag set to `true` [is not considered a direct vulnerability](https://developer.android.com/privacy-and-security/risks/android-debuggable), it significantly increases the attack surface by providing unauthorized access to app data and resources, particularly in production environments.

## Steps

1. Obtain the `AndroidManifest.xml` file using @MASTG-TECH-0117.
2. Search for the `debuggable` flag:
    - Look for `android:debuggable` if analyzing raw XML using tools like @MASTG-TOOL-0011.
    - Look for `application-debuggable` if using @MASTG-TOOL-0124.

## Observation

The output should explicitly show whether the `debuggable` flag is set (`true` or `false`). If the flag is not specified, it is treated as `false` by default for release builds.

## Evaluation

The test case fails if the `debuggable` flag is explicitly set to `true`. This indicates that the app is configured to allow debugging, which is inappropriate for production environments.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0324

---
platform: android
title: References to Root Detection Mechanisms
id: MASTG-TEST-0324
type: [static]
weakness: MASWE-0097
best-practices: [MASTG-BEST-0029, MASTG-BEST-0030]
profiles: [R]
knowledge: [MASTG-KNOW-0027]
---

## Overview

This test checks whether the app implements root detection by statically analyzing the app binary for common root detection patterns. These may include checks for files and artifacts typically associated with rooted devices, as well as calls to known root detection APIs or libraries.

See @MASTG-KNOW-0027 for more information on root detection techniques and specific APIs and artifacts to look for.

This test is best combined with @MASTG-TEST-0325, which performs dynamic testing to confirm whether the identified root detection mechanisms are active at runtime. This way, you can use static analysis to surface potential root detection logic and then focus your dynamic testing on those specific checks to confirm they are triggered at runtime. Alternatively, you can perform dynamic testing first to identify any root detection mechanisms that are active at runtime, and then use static analysis to further investigate their implementation and coverage.

!!! note "Out of Scope"
    This test does not cover robustness or effectiveness of root detection mechanisms, which can be very difficult to assess through static analysis alone and may require manual reverse engineering and custom instrumentation. See @MASTG-BEST-0030 for best practices on implementing root detection effectively and understanding its limitations.

## Steps

1. Use @MASTG-TECH-0014 with appropriate patterns to search for root detection APIs and methods in the decompiled code.

## Observation

The output should contain a list of locations where root detection checks are implemented, including specific methods and file paths being checked.

## Evaluation

The test case fails if the app does not implement any root detection checks. However, note that static analysis may not detect all root detection mechanisms, especially if they are proprietary, obfuscated, or implemented in native code.

If root detection checks are found, this is a positive sign, but you should still evaluate their effectiveness. See @MASTG-BEST-0030.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0263

---
platform: android
title: Logging of StrictMode Violations
id: MASTG-TEST-0263
apis: [StrictMode]
type: [dynamic]
weakness: MASWE-0094
profiles: [R]
---

## Overview

This test checks whether an app enables [`StrictMode`](../../../Document/0x05i-Testing-Code-Quality-and-Build-Settings.md#strictmode) in production. While useful for developers to log policy violations such as disk I/O or network operations in production apps, leaving `StrictMode` enabled can expose sensitive implementation details in the logs that could be exploited by attackers.

## Steps

1. Install the production build of your app on your device or emulator.
2. Uses @MASTG-TECH-0009 to show the system logs `StrictMode` creates.
3. Open the app and let it execute.

## Observation

The output should contain a list of log statements related to `StrictMode`.

## Evaluation

The test fails if an app logs any `StrictMode` policy violations.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0288

---
platform: android
title: Debugging Symbols in Native Binaries
alias: debugging-symbols-in-native-binaries
id: MASTG-TEST-0288
type: [static]
weakness: MASWE-0093
best-practices: []
profiles: [R]
---

## Overview

This test checks whether the app includes debugging symbols in its native binaries. Debugging symbols can provide valuable information during reverse engineering and vulnerability analysis by exposing sensitive implementation details such as function names, variable names, and source file references.

## Steps

1. Run a static analysis (@MASTG-TECH-0140) to retrieve any debugging information present in the native binaries.

## Observation

The output should identify all instances of debugging information in the native binaries.

## Evaluation

The test **fails** if debugging information is present in any native binary, including if actual debugging symbols were successfully extracted.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0244

---
title: Missing Certificate Pinning in Network Traffic
platform: network
id: MASTG-TEST-0244
type: [network]
weakness: MASWE-0047
profiles: [L2]
knowledge: [MASTG-KNOW-0015]
---

## Overview

There are multiple ways an application can implement certificate pinning, including via the Android Network Security Config, custom TrustManager implementations, third-party libraries, and native code. Since some implementations might be difficult to identify through static analysis, especially when obfuscation or dynamic code loading is involved, this test uses network interception techniques to determine if certificate pinning is enforced at runtime.

The goal of this test case is to observe whether a [MITM attack](../../../Document/0x04f-Testing-Network-Communication.md#intercepting-network-traffic-through-mitm) can intercept HTTPS traffic from the app. A successful MITM interception indicates that the app is either not using certificate pinning or implementing it incorrectly.

If the app is properly implementing certificate pinning, the MITM attack should fail because the app rejects certificates issued by an unauthorized CA, even if the CA is trusted by the system.

_Testing Tip:_ While performing the MITM attack, it can be useful to monitor the system logs (see @MASTG-TECH-0009). If a certificate pinning/validation check fails, an event similar to the following log entry might be visible, indicating that the app detected the MITM attack and did not establish a connection.

`I/X509Util: Failed to validate the certificate chain, error: Pin verification failed`

## Steps

1. Set up an interception proxy, see @MASTG-TECH-0011.
2. Install the application on a device connected to that proxy, and intercept the communication.
3. Extract all domains which were intercepted.

## Observation

The output should contain a list of domains for which the interception was successful.

## Evaluation

The test case fails if any relevant domain was intercepted.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0234

---
title: Missing Implementation of Server Hostname Verification with SSLSockets
platform: android
id: MASTG-TEST-0234
type: [static]
weakness: MASWE-0052
profiles: [L1, L2]
---

## Overview

This test checks whether an Android app uses [`SSLSocket`](https://developer.android.com/reference/javax/net/ssl/SSLSocket) without a [`HostnameVerifier`](https://developer.android.com/reference/javax/net/ssl/HostnameVerifier), allowing connections to servers presenting certificates with **wrong or invalid hostnames**.

By default, `SSLSocket` [does not perform hostname verification](https://developer.android.com/privacy-and-security/security-ssl#WarningsSslSocket). To enforce it, the app must explicitly invoke [`HostnameVerifier.verify()`](https://developer.android.com/reference/javax/net/ssl/HostnameVerifier#verify%28java.lang.String,%20javax.net.ssl.SSLSession%29) and implement proper checks.

Such unsafe implementations can allow an attacker to run a [MITM attack](../../../Document/0x04f-Testing-Network-Communication.md#intercepting-network-traffic-through-mitm) with a valid (or self-signed) certificate and intercept or tamper with the app's traffic.

**Note:** The connection succeeds even if the app has a fully secure Network Security Configuration (NSC) in place because `SSLSocket` is not affected by it.

## Steps

1. Reverse engineer the app (@MASTG-TECH-0017).
2. Run a static analysis (@MASTG-TECH-0014) tool and look for all usages of `SSLSocket` and `HostnameVerifier`.

## Observation

The output should contain a list of locations where `SSLSocket` and `HostnameVerifier` are used.

## Evaluation

The test case fails if the app uses `SSLSocket` without a `HostnameVerifier`.

**Note:** If a `HostnameVerifier` is present, ensure it's not implemented in an unsafe manner. See @MASTG-TEST-0283 for guidance.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0283

---
title: Incorrect Implementation of Server Hostname Verification
platform: android
id: MASTG-TEST-0283
type: [static]
weakness: MASWE-0052
profiles: [L1, L2]
---

## Overview

This test evaluates whether an Android app implements a [`HostnameVerifier`](https://developer.android.com/reference/javax/net/ssl/HostnameVerifier) that uses [`verify(...)`](https://developer.android.com/reference/javax/net/ssl/HostnameVerifier#verify(java.lang.String,%20javax.net.SSL.SSLSession)) [in an unsafe manner](https://developer.android.com/privacy-and-security/risks/unsafe-hostname), effectively turning off hostname validation for the affected connections.

Such unsafe implementations can allow an attacker to run a [MITM attack](../../../Document/0x04f-Testing-Network-Communication.md#intercepting-network-traffic-through-mitm) with a valid (or self-signed) certificate and intercept or tamper with the app's traffic.

## Steps

1. Reverse engineer the app (@MASTG-TECH-0017).
2. Inspect the source code and run a static analysis (@MASTG-TECH-0014) tool and look for all usages of `HostnameVerifier`.

## Observation

The output should contain a list of locations where `HostnameVerifier` is used.

## Evaluation

The test fails if the app does **not** properly validate that the server's hostname matches the certificate.

This includes cases such as:

- **Always accepting hostnames:** overriding `verify(...)` to unconditionally return `true`, regardless of the actual hostname or certificate.
- **Overly broad matching rules:** using permissive wildcard logic that matches unintended domains.
- **Incomplete verification coverage:** failing to invoke hostname verification on all SSL/TLS channels, such as those created via `SSLSocket`, or during renegotiation.
- **Missing manual verification:** not performing hostname verification when it is not done automatically, such as when using the low-level `SSLSocket` API.

When testing using automated tools, you will need to inspect all the reported locations in the reverse-engineered code to confirm the incorrect implementation (@MASTG-TECH-0023).
OWASP Mobile Application Security Testing Guide: MASTG TEST 0284

---
title: Incorrect SSL Error Handling in WebViews
platform: android
id: MASTG-TEST-0284
type: [static]
weakness: MASWE-0052
best-practices: [MASTG-BEST-0021]
profiles: [L1, L2]
knowledge: [MASTG-KNOW-0010]
---

## Overview

This test evaluates whether an Android app has WebViews that ignore SSL/TLS certificate errors by overriding the [`onReceivedSslError(...)`](https://developer.android.com/reference/android/webkit/WebViewClient#onReceivedSslError%28android.webkit.WebView,%20android.webkit.SslErrorHandler,%20android.net.http.SslError%29) method without proper validation.

The method `onReceivedSslError(...)` is triggered when a `WebView` encounters an SSL certificate error while loading a page. By default, the `WebView` cancels the request to protect users from insecure connections. Overriding this method and calling [`SslErrorHandler.proceed()`](https://developer.android.com/reference/android/webkit/SslErrorHandler#proceed%28%29) without proper validation disables these protection.

This effectively bypasses SSL certificate checks in the `WebView`, exposing the app to [MITM attacks](../../../Document/0x04f-Testing-Network-Communication.md#intercepting-network-traffic-through-mitm) using invalid, expired, or self-signed certificates.

## Steps

1. Reverse engineer the app (@MASTG-TECH-0017).
2. Inspect the source code and run a static analysis (@MASTG-TECH-0014) tool and look for all usages of `onReceivedSslError(...)`.

## Observation

The output should contain a list of locations where `onReceivedSslError(...)` that includes a `proceed()` is used without exception handling that properly handles SSL errors.

## Evaluation

The test fails if `onReceivedSslError(...)` is overridden and certificate errors are ignored without proper validation or user involvement.

This includes cases such as:

- **Unconditionally accepting SSL errors:** calling `proceed()` without checking the nature of the error.
- **Relying only on primary error code:** using [`getPrimaryError()`](https://developer.android.com/reference/android/net/http/SslError#getPrimaryError()) for decision-making, such as proceeding if the primary error is not `SSL_UNTRUSTED`, which may overlook additional errors in the chain.
- **Suppressing exceptions silently:** catching exceptions in `onReceivedSslError(...)` without calling [`cancel()`](https://developer.android.com/reference/android/webkit/SslErrorHandler#cancel()), which allows the connection to continue silently.

According to [official Android guidance](https://developer.android.com/reference/android/webkit/WebViewClient.html#onReceivedSslError(android.webkit.WebView,%20android.webkit.SslErrorHandler,%20android.net.http.SslError)), apps should never call `proceed()` in response to SSL errors. The correct behavior is to cancel the request to protect users from potentially insecure connections. User prompts are also discouraged, as users cannot reliably evaluate SSL issues.

When testing using automated tools, you will need to inspect all the reported locations in the reverse-engineered code to confirm the incorrect implementation (@MASTG-TECH-0023).
OWASP Mobile Application Security Testing Guide: MASTG TEST 0236

---
title: Cleartext Traffic Observed on the Network
platform: network
id: MASTG-TEST-0236
type: [dynamic]
weakness: MASWE-0050
profiles: [L1, L2]
---

## Overview

This test intercepts the app's incoming and outgoing network traffic, and checks for any cleartext communication.
Whilst the static checks can only show _potential_ cleartext traffic, this dynamic test shows all communication the application definitely makes.

!!! warning Limitation
    - Intercepting traffic on a network level will show all traffic _the device_ performs, not only the single app. Linking the traffic back to a specific app can be difficult, especially when more apps are installed on the device.
    - Linking the intercepted traffic back to specific locations in the app can be difficult and requires manual analysis of the code.
    - Dynamic analysis works best when you interact extensively with the app. But even then there could be corner cases which are difficult or impossible to execute on every device. The results from this test therefore are likely not exhaustive.

## Steps

You can use one of the following approaches:

- Set up @MASTG-TECH-0010 (for Android) or @MASTG-TECH-0062 (for iOS) to capture all traffic.
- Set up @MASTG-TECH-0011 (for Android) or @MASTG-TECH-0063 (for iOS) to capture all traffic.

**Notes**:

- Interception proxies will show HTTP(S) traffic only. You can, however, use some tool-specific plugins such as [Burp-non-HTTP-Extension](https://github.com/summitt/Burp-Non-HTTP-Extension) or other tools like @MASTG-TOOL-0078 to decode and visualize communication via XMPP and other protocols.
- Some apps may not function correctly with proxies like Burp and @MASTG-TOOL-0079 because of certificate pinning. In such a scenario, you can still use basic network sniffing to detect cleartext traffic. Otherwise, you can try to disable pinning (see @MASTG-TECH-0012 for Android and @MASTG-TECH-0064 for iOS)

## Observation

The output should contain the captured network traffic.

## Evaluation

The test case fails if any clear text traffic originates from the target app.

!!! note
    This can be challenging to determine because traffic can potentially come from any app on the device. See the [Overview](#overview) section.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0242

---
title: Missing Certificate Pinning in Network Security Configuration
platform: android
id: MASTG-TEST-0242
type: [static]
weakness: MASWE-0047
profiles: [L2]
knowledge: [MASTG-KNOW-0014, MASTG-KNOW-0015]
---

## Overview

Apps can configure [certificate pinning using the Network Security Configuration](../../../knowledge/android/MASVS-NETWORK/MASTG-KNOW-0015.md#pinning-via-network-security-configuration-api-24). For each domain, one or multiple digests can be pinned.

The goal of this test is to check if the app does not implement certificate pinning using the NSC. However, note that the app may be using other pinning methods covered in other tests.

## Steps

1. Reverse engineer the app (@MASTG-TECH-0017).
2. Obtain the AndroidManifest.xml (@MASTG-TECH-0117), and check if a `networkSecurityConfig` is set in the `<application>` tag.
3. Inspect the referenced network security config file, and extract all domains from `<domain-config>` which have a pin set (`<pin-set>`).

## Observation

The output should contain a list of domains which enable certificate pinning.

## Evaluation

The test case fails if no `networkSecurityConfig` is set, or any relevant domain does not enable certificate pinning.