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

---
title: Unsafe Custom Trust Evaluation
platform: android
id: MASTG-TEST-0282
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 uses [`checkServerTrusted(...)`](https://developer.android.com/reference/javax/net/ssl/X509TrustManager#checkServerTrusted%28java.security.cert.X509Certificate[],%20java.lang.String%29) [in an unsafe manner](https://developer.android.com/privacy-and-security/risks/unsafe-trustmanager) as part of a custom `TrustManager`, causing any connection configured to use that `TrustManager` to skip certificate validation.

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. Run a static analysis (@MASTG-TECH-0014) tool for the app and look for all usages of `checkServerTrusted(...)`.

## Observation

The output should contain a list of locations where `checkServerTrusted(...)` is used.

## Evaluation

The test fails if `checkServerTrusted(...)` is implemented in a custom `X509TrustManager` and does **not** properly validate server certificates.

This includes cases such as:

- **Using `checkServerTrusted(...)` which is error prone, when NSC would be enough.
- **Trust manager that does nothing:** overriding `checkServerTrusted(...)` to accept all certificates without any validation, for example by returning immediately without verifying the certificate chain or by always returning `true`.
- **Ignoring errors:** failing to [throw proper exceptions](https://support.google.com/faqs/answer/6346016) (e.g. [`CertificateException`](https://developer.android.com/reference/java/security/cert/CertificateException.html) or [`IllegalArgumentException`](https://developer.android.com/reference/java/lang/IllegalArgumentException)) on validation failure, or catching and suppressing them.
- **Using [`checkValidity()`](https://developer.android.com/reference/java/security/cert/X509Certificate#checkValidity()) instead of full validation:** relying only on `checkValidity()` checks whether the certificate is expired or not yet valid, but does **not** verify trust or hostname matching.
- **Explicitly loosening trust:** disabling trust checks to accept self-signed or untrusted certificates for convenience during development or testing.
- **Misusing [`getAcceptedIssuers()`](https://developer.android.com/reference/javax/net/ssl/X509TrustManager#getAcceptedIssuers())**: Returning `null` or an empty array without proper handling may effectively disable issuer validation.

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 0243

---
title: Expired Certificate Pins in the Network Security Configuration 
platform: android
id: MASTG-TEST-0243
type: [static]
weakness: MASWE-0047
profiles: [L2]
knowledge: [MASTG-KNOW-0014, MASTG-KNOW-0015]
---

## Overview

Apps can configure expiration dates for pinned certificates in the Network Security Configuration (NSC) (@MASTG-KNOW-0014) by using the `expiration` attribute. When a pin expires, the app no longer enforces certificate pinning and instead relies on its configured trust anchors. This means the connection will still succeed if the server presents a valid certificate from a trusted CA (such as a system CA or a custom CA defined in the app's configuration). However, if no trusted certificate is available, the connection will fail.

If developers assume pinning is still in effect but don't realize it has expired, the app may start trusting CAs it was never intended to.

> Example: A financial app previously pinned to its own private CA but, after expiration, starts trusting publicly trusted CAs, increasing the risk of compromise if a CA is breached.

The goal of this test is to check if any expiration date is in the past.

## Steps

1. Reverse engineer the app (@MASTG-TECH-0017).
2. Inspect the AndroidManifest.xml, and check if a `networkSecurityConfig` is set in the `<application>` tag. If yes, inspect the referenced file, and extract the expiration dates for every domain.

## Observation

The output should contain a list of expiration dates for pinned certificates.

## Evaluation

The test case fails if any expiration date is in the past.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0239

---
title: Using low-level APIs (e.g. Socket) to set up a custom HTTP connection
platform: android
id: MASTG-TEST-0239
type: [static]
weakness: MASWE-0050
status: placeholder
note: This test could also be for MASWE-0049 but we'd need to support multiple weaknesses.
profiles: [L1, L2]
---
OWASP Mobile Application Security Testing Guide: MASTG TEST 0285

---
title: Outdated Android Version Allowing Trust in User-Provided CAs
platform: android
id: MASTG-TEST-0285
type: [static]
deprecated_since: 24
weakness: MASWE-0052
profiles: [L1, L2]
knowledge: [MASTG-KNOW-0014]
---

## Overview

This test evaluates whether an Android app **implicitly** trusts user-added CA certificates by [default](https://developer.android.com/privacy-and-security/security-config#CustomTrust), which is the case for apps that can be installed to devices running API level 23 or lower.

Those apps rely on the default Network Security Configuration that trusts both system and user-installed Certificate Authorities (CAs). Such trust can expose the app to [MITM attacks](../../../Document/0x04f-Testing-Network-Communication.md#intercepting-network-traffic-through-mitm), as malicious CAs installed by users could intercept secure communications.

## Steps

1. Obtain the AndroidManifest.xml (@MASTG-TECH-0117).
2. Read the value of the `minSdkVersion` attribute from the `<uses-sdk>` element.

## Observation

The output should contain the value of `minSdkVersion`.

## Evaluation

The test case fails if `minSdkVersion` is less than 24.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0237

---
title: Cross-Platform Framework Configurations Allowing Cleartext Traffic
platform: android
id: MASTG-TEST-0237
type: [static]
weakness: MASWE-0050
status: placeholder
note: Cross-platform frameworks (e.g. Flutter, React native, ...), typically have their own implementations for HTTP libraries, where cleartext traffic can be allowed.
profiles: [L1, L2]
---
OWASP Mobile Application Security Testing Guide: MASTG TEST 0217

---
title: Insecure TLS Protocols Explicitly Allowed in Code
platform: android
id: MASTG-TEST-0217
type: [static]
weakness: MASWE-0050
profiles: [L1, L2]
---

## Overview

The Android Network Security Configuration does not provide direct control over specific TLS versions (unlike [iOS](https://developer.apple.com/documentation/bundleresources/information_property_list/nsexceptionminimumtlsversion)), and starting with Android 10, [TLS v1.3 is enabled by default](https://developer.android.com/privacy-and-security/security-ssl#Updates%20to%20SSL) for all TLS connections.

There are still several ways to enable insecure versions of TLS, including:

### Java Sockets

An app can obtain an SSLContext using an insecure TLS protocol by calling `SSLContext.getInstance("TLSv1.1")` and can also enable specific, potentially insecure, protocol versions using the API call `javax.net.ssl.SSLSocket.setEnabledProtocols(String[] protocols)`.

### Third-party Libraries

Some third-party libraries, such as [OkHttp](https://square.github.io/okhttp/), [Retrofit](https://square.github.io/retrofit/) or Apache HttpClient, provide custom configurations for TLS protocols. These libraries may allow enabling outdated protocols if not carefully managed:

For example, using `ConnectionSpec.COMPATIBLE_TLS` in OkHttp (via `okhttp3.ConnectionSpec.Builder.connectionSpecs(...)`) can lead to insecure TLS versions, like TLS 1.1, being enabled by default in certain versions. Refer to OkHttp's [configuration history](https://square.github.io/okhttp/security/tls_configuration_history/) for details on supported protocols.

The API call `okhttp3.ConnectionSpec.Builder.tlsVersions(...)` can also be used to set the enabled protocols ([OkHttp documentation](https://square.github.io/okhttp/features/https/)).

## Steps

1. Reverse engineer the app (@MASTG-TECH-0017).
2. Run a static analysis (@MASTG-TECH-0014) tool on the reverse engineered app targeting calls to APIs setting the TLS protocol.

## Observation

The output should contain a list of all enabled TLS versions in the above mentioned API calls.

## Evaluation

The test case fails if any [insecure TLS version](../../../Document/0x04f-Testing-Network-Communication.md#recommended-tls-settings) is directly enabled, or if the app enabled any settings allowing the use of outdated TLS versions, such as `okhttp3.ConnectionSpec.COMPATIBLE_TLS`.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0286

---
title: Network Security Configuration Allowing Trust in User-Provided CAs
platform: android
id: MASTG-TEST-0286
type: [static]
weakness: MASWE-0052
profiles: [L1, L2]
knowledge: [MASTG-KNOW-0014]
---

## Overview

This test evaluates whether an Android app **explicitly** trusts user-added CA certificates by including [`<certificates src="user"/>`](https://developer.android.com/privacy-and-security/security-config#certificates) in its [Network Security Configuration](https://developer.android.com/privacy-and-security/security-config#CustomTrust). Even though starting with Android 7.0 (API level 24) apps no longer trust user-added CAs by default, this configuration overrides that behavior.

Such trust can expose the application to [MITM attacks](../../../Document/0x04f-Testing-Network-Communication.md#intercepting-network-traffic-through-mitm), as malicious CAs installed by users could intercept secure communications.

## Steps

1. Obtain the AndroidManifest.xml (@MASTG-TECH-0117).
2. Check if an [`android:networkSecurityConfig`](https://developer.android.com/guide/topics/manifest/application-element#networkSecurityConfig) attribute is set in the `<application>` tag.
3. Inspect the referenced Network Security Configuration file, and extract all uses of `<certificates src="user" />`.

## Observation

The output should contain all the `<trust-anchors>` from the Network Security Configuration file along with any defined `<certificates>` entries, if present.

## Evaluation

The test case fails if `<certificates src="user" />` has been defined as part of the `<trust-anchors>` in the Network Security Configuration file.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0295

---
title: GMS Security Provider Not Updated
platform: android
id: MASTG-TEST-0295
type: [static]
weakness: MASWE-0052
profiles: [L2]
best-practices: [MASTG-BEST-0020]
knowledge: [MASTG-KNOW-0011, MASTG-KNOW-0010]
---

## Overview

This test checks whether the Android app ensures the Security Provider is [updated to mitigate SSL/TLS vulnerabilities](https://developer.android.com/privacy-and-security/security-gms-provider). The provider should be updated using Google Play Services APIs, and the implementation should handle exceptions properly.

## Steps

1. Reverse engineer the app (@MASTG-TECH-0017).
2. Use static analysis (@MASTG-TECH-0014) to search for usage of `ProviderInstaller.installIfNeeded` or `ProviderInstaller.installIfNeededAsync`.

## Observation

The output should list all locations where the Security Provider update is performed and how exceptions are handled (for `installIfNeeded`), or how the `ProviderInstallListener` handles errors (for `installIfNeededAsync`).

## Evaluation

The test fails if the app does not update the provider, or it does not handle exceptions properly. Check that these calls occur before any network connections are made.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0233

---
title: Hardcoded HTTP URLs
platform: android
id: MASTG-TEST-0233
type: [static]
weakness: MASWE-0050
related-tests: [MASTG-TEST-0235, MASTG-TEST-0236, MASTG-TEST-0238]
profiles: [L1, L2]
---

## Overview

An Android app may have hardcoded HTTP URLs embedded in the app binary, library binaries, or other resources within the APK. These URLs may indicate potential locations where the app communicates with servers over an unencrypted connection.

!!! warning Limitations
    The presence of HTTP URLs alone does not necessarily mean they are actively used for communication. Their usage may depend on runtime conditions, such as how the URLs are invoked and whether cleartext traffic is allowed in the app's configuration. For example, HTTP requests may fail if cleartext traffic is disabled in the AndroidManifest.xml or restricted by the Network Security Configuration. See @MASTG-TEST-0235.

## Steps

1. Reverse engineer the app (@MASTG-TECH-0017).
2. Run a static analysis (@MASTG-TECH-0014) tool and look for any `http://` URLs.

## Observation

The output should contain a list of URLs and their locations within the app.

## Evaluation

The test case fails if any HTTP URLs are confirmed to be used for communication.

The presence of hardcoded HTTP URLs does not inherently mean they are used; their actual usage must be validated through careful inspection and testing:

- **Reverse Engineering**: Inspect the code locations where the HTTP URLs are referenced. Determine if they are merely stored as constants or actively used to create HTTP requests through networking APIs like `HttpURLConnection` or `OkHttp`.
- **Static Analysis**: Analyze the app's configuration to identify whether cleartext traffic is permitted. For example, check the AndroidManifest.xml for `android:usesCleartextTraffic="true"` or inspect the `network_security_config`. Refer to @MASTG-TEST-0235 for detailed guidance.

Additionally, complement this static inspection with dynamic testing methods:

- **Dynamic Analysis**: Use tools like Frida to hook into networking APIs at runtime. This can reveal how and when the HTTP URLs are used during execution. See @MASTG-TEST-0238 for more details.

- **Network Traffic Interception**: Capture and analyze network traffic using tools like Burp Suite, mitmproxy, or Wireshark. This approach confirms whether the app connects to the identified HTTP URLs during real-world usage but depends on the tester's ability to exercise the app's functionality comprehensively. See @MASTG-TEST-0236.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0235

---
title: Android App Configurations Allowing Cleartext Traffic
platform: android
id: MASTG-TEST-0235
type: [static]
weakness: MASWE-0050
profiles: [L1, L2]
knowledge: [MASTG-KNOW-0014]
---

## Overview

Since Android 9 (API level 28) cleartext HTTP traffic is blocked by default (thanks to the [default Network Security Configuration](../../../Document/0x05g-Testing-Network-Communication.md#default-configurations)) but there are multiple ways in which an application can still send it:

- **AndroidManifest.xml**: Setting the [`android:usesCleartextTraffic`](https://developer.android.com/guide/topics/manifest/application-element#usesCleartextTraffic) attribute of the `<application>` tag. Note that this flag is ignored in case the Network Security Configuration is configured.
- **Network Security Configuration**: Setting the [`cleartextTrafficPermitted`](https://developer.android.com/privacy-and-security/security-config#CleartextTrafficPermitted) attribute to `true` on `<base-config>` or `<domain-config>` elements.

## Steps

1. Reverse engineer the app (@MASTG-TECH-0017).
2. Obtain the AndroidManifest.xml.
3. Obtain the Network Security Configuration.
4. Read the value of `usesCleartextTraffic` from the AndroidManifest.xml.
5. Read the value of `cleartextTrafficPermitted` from the NSC `<base-config>` element.
6. Read the value of `cleartextTrafficPermitted` from the NSC `<domain-config>` elements.

## Observation

The output should contain a list of configurations potentially allowing for cleartext traffic.

## Evaluation

The test case fails if cleartext traffic is permitted. This can happen if any of the following is true:

1. The AndroidManifest sets `usesCleartextTraffic` to `true` and there's no NSC.
2. The NSC sets `cleartextTrafficPermitted` to `true` in the `<base-config>`.
3. The NSC sets `cleartextTrafficPermitted` to `true` in any `<domain-config>`.

**Note:** The test doesn't fail if the AndroidManifest sets `usesCleartextTraffic` to `true` and there's a NSC, even if it only has an empty `<network-security-config>` element. For example:

```xml
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
</network-security-config>
```
OWASP Mobile Application Security Testing Guide: MASTG TEST 0238

---
title: Runtime Use of Network APIs Transmitting Cleartext Traffic
platform: android
id: MASTG-TEST-0238
type: [dynamic]
weakness: MASWE-0050
status: placeholder
note: Using Frida, you can trace all traffic of the app, mitigating the limitation of the dynamic analysis that you do not know which app, or which location is responsible for the traffic. Using Frida (and `.backtrace()`), you can be sure this is from the analyzed app, and know the exact location. A new limitation is then that all relevant networking APIs need to be instrumented.
profiles: [L1, L2]
---
OWASP Mobile Application Security Testing Guide: MASTG TEST 0218

---
title: Insecure TLS Protocols in Network Traffic
platform: network
id: MASTG-TEST-0218
type: [network]
weakness: MASWE-0050
profiles: [L1, L2]
---

## Overview

While static analysis can identify configurations that allow insecure TLS versions, it may not accurately reflect the actual protocol used during live communications. This is because TLS version negotiation occurs between the client (app) and the server at runtime, where they agree on the most secure, mutually supported version.

By capturing and analyzing real network traffic, you can observe the TLS version actually negotiated and in use. This approach provides an accurate view of the protocol's security, accounting for the server's configuration, which may enforce or limit specific TLS versions.

In cases where static analysis is either incomplete or infeasible, examining network traffic can reveal instances where insecure TLS versions (e.g., TLS 1.0 or TLS 1.1) are actively in use.

## Steps

1. Set up @MASTG-TECH-0010 (for Android) or @MASTG-TECH-0062 (for iOS).
2. View the TLS version e.g., using @MASTG-TOOL-0081.

## Observation

The output should contain the TLS version actually used during the connection.

## Evaluation

The test case fails if any [insecure TLS version](../../../Document/0x04f-Testing-Network-Communication.md#recommended-tls-settings) is used.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0291

---
title: References to Screen Capturing Prevention APIs
platform: android
id: MASTG-TEST-0291
type: [static]
profiles: [L2]
best-practices: [MASTG-BEST-0014]
weakness: MASWE-0055
knowledge: [MASTG-KNOW-0053]
---

## Overview

This test verifies whether an app references Android screen capture prevention APIs. On Android, developers can prevent screenshots and nonsecure display mirroring using [`FLAG_SECURE`](https://developer.android.com/security/fraud-prevention/activities#flag_secure). When set, Android blocks screenshots and prevents content from appearing on a nonsecure display, including remote screen sharing. Users see a blank screen if they attempt a screenshot or when the app moves to the background.

Developers typically apply the flag with [`addFlags()`](https://developer.android.com/reference/android/view/Window#addFlags(int)) or [`setFlags()`](https://developer.android.com/reference/android/view/Window#setFlags(int,int)). Common failure modes include not setting `FLAG_SECURE` on all sensitive screens or clearing the flag during transitions e.g., using [`clearFlags()`](https://developer.android.com/reference/android/view/Window#clearFlags(int)) or `setFlags()`.

## Steps

1. Run a static analysis (@MASTG-TECH-0014) tool to identify instances of the relevant APIs.

## Observation

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

## Evaluation

The test case fails if the relevant APIs are missing or inconsistently applied on any UI component that displays sensitive data, or if code paths clear the protection without an adequate justification.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0340

---
platform: android
title: References to Overlay Attack Protections
id: MASTG-TEST-0340
apis: [onFilterTouchEventForSecurity, setFilterTouchesWhenObscured, FLAG_WINDOW_IS_OBSCURED, FLAG_WINDOW_IS_PARTIALLY_OBSCURED]
type: [static]
weakness: MASWE-0053
best-practices: [MASTG-BEST-0040]
profiles: [L2]
knowledge: [MASTG-KNOW-0022]
---

## Overview

Overlay attacks (also known as tapjacking) allow malicious apps to place deceptive UI elements over a legitimate app's interface, potentially tricking users into performing unintended actions such as granting permissions, revealing credentials, or authorizing payments. If the app does not implement appropriate protections, users can interact with overlaid malicious content while believing they are interacting with the legitimate app.

Android provides several mechanisms to protect against overlay attacks through touch filtering. These mechanisms can detect when a view is obscured and filter touch events accordingly. However, if the app does not use these protections on sensitive UI elements, it remains vulnerable to overlay attacks.

This test checks whether the app implements overlay attack protections by looking for references to touch filtering APIs and attributes that prevent interaction when views are obscured.

These include:

- The `setFilterTouchesWhenObscured` method.
- The `android:filterTouchesWhenObscured` attribute in layout files.
- The `onFilterTouchEventForSecurity` method.
- Checks for `FLAG_WINDOW_IS_OBSCURED` or `FLAG_WINDOW_IS_PARTIALLY_OBSCURED` flags.
- The [`setHideOverlayWindows`](https://developer.android.com/reference/android/view/Window#setHideOverlayWindows(boolean)) method and the required `HIDE_OVERLAY_WINDOWS` permission for API level 31 and above.

## Steps

1. Use @MASTG-TECH-0014 to search for references to overlay protection mechanisms.
2. Use @MASTG-TECH-0117 to obtain the AndroidManifest.xml file and check the `targetSdkVersion` and any relevant permissions.

## Observation

The output should contain:

- A list of locations where overlay protection mechanisms are used
- The app's `targetSdkVersion`
- Any relevant permissions, such as `HIDE_OVERLAY_WINDOWS`

## Evaluation

The test fails if the app handles sensitive user interactions (such as login, payment confirmation, permission requests, or security settings) and does not implement any overlay attack protections on those sensitive UI elements.

For example:

- The app doesn't implement `setFilterTouchesWhenObscured(true)` or `android:filterTouchesWhenObscured="true"` on sensitive UI elements.
- The app doesn't override `onFilterTouchEventForSecurity` to implement custom security policies.
- The app doesn't check for `FLAG_WINDOW_IS_OBSCURED` or `FLAG_WINDOW_IS_PARTIALLY_OBSCURED` in touch event handlers for sensitive interactions.
- The app targets API level 31 or higher but does not use `setHideOverlayWindows(true)` and declare the `HIDE_OVERLAY_WINDOWS` permission.