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

---
platform: android
title: Runtime Use of Local File Access APIs in WebViews
alias: references-to-local-file-access-in-webviews
id: MASTG-TEST-0253
apis: [WebView, WebSettings, getSettings, setAllowFileAccess, setAllowFileAccessFromFileURLs, setAllowUniversalAccessFromFileURLs]
type: [dynamic]
weakness: MASWE-0069
best-practices: [MASTG-BEST-0010, MASTG-BEST-0011, MASTG-BEST-0012]
profiles: [L1, L2]
knowledge: [MASTG-KNOW-0018]
---

## Overview

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

## Steps

1. Run a dynamic analysis tool like @MASTG-TOOL-0001 and either:
    - enumerate instances of `WebView` in the app and list their configuration values
    - or explicitly hook the setters of the `WebView` settings

## Observation

The output should contain a list of WebView instances and corresponding settings.

## Evaluation

**Fail:**

The test fails if all of the following are true:

- `AllowFileAccess` is `true`.
- `AllowFileAccessFromFileURLs` is `true`.
- `AllowUniversalAccessFromFileURLs` is `true`.

**Note:** `AllowFileAccess` being `true` does not represent a security vulnerability by itself, but it can be used in combination with other vulnerabilities to escalate the impact of an attack. Therefore, it is recommended to explicitly set it to `false` if the app does not need to access local files.

**Pass:**

The test passes if any of the following are true:

- `AllowFileAccess` is `false`.
- `AllowFileAccessFromFileURLs` is `false`.
- `AllowUniversalAccessFromFileURLs` is `false`.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0251

---
platform: android
title: Runtime Use of Content Provider Access APIs in WebViews
alias: references-to-content-provider-access-in-webviews
id: MASTG-TEST-0251
apis: [WebView, WebSettings, getSettings, ContentProvider, setAllowContentAccess, setAllowUniversalAccessFromFileURLs, setJavaScriptEnabled]
type: [dynamic]
weakness: MASWE-0069
best-practices: [MASTG-BEST-0011, MASTG-BEST-0012, MASTG-BEST-0013]
profiles: [L1, L2]
knowledge: [MASTG-KNOW-0018]
---

## Overview

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

## Steps

1. Run a dynamic analysis tool like @MASTG-TOOL-0001 and either:
    - enumerate instances of `WebView` in the app and list their configuration values
    - or explicitly hook the setters of the `WebView` settings

## Observation

The output should contain a list of WebView instances and corresponding settings.

## Evaluation

**Fail:**

The test fails if all of the following are true:

- `JavaScriptEnabled` is `true`.
- `AllowContentAccess` is `true`.
- `AllowUniversalAccessFromFileURLs` is `true`.

You should use the list of content providers obtained in @MASTG-TEST-0250 to verify if they handle sensitive data.

**Note:** `AllowContentAccess` being `true` does not represent a security vulnerability by itself, but it can be used in combination with other vulnerabilities to escalate the impact of an attack. Therefore, it is recommended to explicitly set it to `false` if the app does not need to access content providers.

**Pass:**

The test passes if any of the following are true:

- `JavaScriptEnabled` is `false`.
- `AllowContentAccess` is `false`.
- `AllowUniversalAccessFromFileURLs` is `false`.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0334

---
platform: android
title: Native Code Exposed Through WebViews
id: MASTG-TEST-0334
type: [static]
weakness: MASWE-0069
best-practices: [MASTG-BEST-0011, MASTG-BEST-0012, MASTG-BEST-0013, MASTG-BEST-0035]
profiles: [L1, L2]
knowledge: [MASTG-KNOW-0018]
prerequisites:
- identify-security-relevant-contexts
---

## Overview

This test verifies Android apps that use WebViews with [legacy WebView-Native bridges](https://developer.android.com/develop/ui/views/layout/webapps/native-api-access-jsbridge#addjavascriptinterface) do not expose native code to websites loaded inside the WebView.

These bridges are created by registering a Java object with the WebView through [`addJavascriptInterface`](https://developer.android.com/reference/kotlin/android/webkit/WebView#addjavascriptinterface). Public methods of that object that are annotated with [`@JavascriptInterface`](https://developer.android.com/reference/android/webkit/JavascriptInterface) become callable from JavaScript running inside the WebView, using the provided `name` as the global JavaScript object.

For this mechanism to work, JavaScript execution must be enabled on the WebView by calling [`WebSettings.setJavaScriptEnabled(true)`](https://developer.android.com/reference/android/webkit/WebSettings#setJavaScriptEnabled(boolean)) (default is `false`), since the exposed interface is invoked from JavaScript code executed within the page.

## Steps

1. Use @MASTG-TECH-0013 to reverse engineer the app.
2. Use @MASTG-TECH-0014 to look for references to the relevant WebView APIs.

## Observation

The output should contain any references to the relevant WebView APIs.

## Evaluation

The test case fails if all the following are true:

- `setJavaScriptEnabled` is explicitly set to `true`.
- `addJavascriptInterface` is used at least once.
- At least one method annotated with `@JavascriptInterface` handles sensitive data or actions and is reachable from untrusted content. See below.

**Context Considerations**:

To reduce false positives, make sure you understand the context in which the bridge is being used before reporting the associated code as insecure. Ensure that it is being used in a security-relevant context to protect sensitive data or actions, and that it is reachable from untrusted content. For example, if the WebView can load arbitrary or weakly validated URLs, or if the app does not implement proper origin allowlisting for the bridge.

**Well-known Challenges when testing for WebView-Native bridges**:

- The app may use parametrized or indirect calls to these APIs, for example through utility methods or wrapper classes. Static analysis may not be able to resolve these calls, and dynamic analysis may require specific app states or user interactions to trigger them.
- The app may use several WebViews with different configurations, and it may be difficult to determine which values are set for each WebView instance, especially if they are created dynamically, in different code paths or even across different files.
- The app may use obfuscation, reflection, or dynamic code loading to hide the use of these APIs.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0258

---
platform: android
title: References to Keyboard Caching Attributes in UI Elements
id: MASTG-TEST-0258
type: [static]
weakness: MASWE-0053
best-practices: [MASTG-BEST-0019]
profiles: [L2]
knowledge: [MASTG-KNOW-0055]
---

## Overview

This test verifies that the app appropriately configures text input fields to prevent the keyboard from caching sensitive information, such as passwords or personal data.

Android apps can configure the behavior of text input fields using XML attributes in the layout files or programmatically in the code. If the app doesn't use non-caching input types for sensitive data, the keyboard may cache sensitive information.

## Steps

1. Reverse engineer the app (@MASTG-TECH-0017).
2. Search for XML attributes in the layout files within the `res/layout` directory.
3. Search for calls to the `setInputType` method and the input type values passed to it (@MASTG-TECH-0014).
4. In case the app uses Jetpack Compose, search for calls to [`KeyboardOptions` constructors](https://developer.android.com/reference/kotlin/androidx/compose/foundation/text/KeyboardOptions#public-constructors_1) and their parameters in the reversed code (@MASTG-TECH-0014). Especially `keyboardType` and `autoCorrect`.

## Observation

The output should include:

- All `android:inputType` XML attributes, if using XML for the UI.
- All calls to the `setInputType` method and the input type values passed to it.

## Evaluation

The test case fails if there are any fields handling sensitive data for which the app does not use non-caching input types (see section "Non-Caching Input Types" in @MASTG-KNOW-0055).
OWASP Mobile Application Security Testing Guide: MASTG TEST 0293

---
title: "`setSecure` Not Used to Prevent Screenshots in SurfaceViews"
platform: android
id: MASTG-TEST-0293
type: [static]
profiles: [L2]
best-practices: [MASTG-BEST-0014, MASTG-BEST-0017]
weakness: MASWE-0055
knowledge: [MASTG-KNOW-0053]
status: placeholder
note: This test verifies whether an app prevents sensitive data from being captured in screenshots and screen recordings of `SurfaceView` components.
---
OWASP Mobile Application Security Testing Guide: MASTG TEST 0316

---
platform: android
title: App Exposing User Authentication Data in Text Input Fields
id: MASTG-TEST-0316
type: [static, manual]
weakness: MASWE-0053
profiles: [L2]
---

## Overview

This test verifies that the app handles user input correctly, ensuring that access codes (passwords or pins) and verification codes (OTPs) are not exposed in plain text within text input fields.

Proper masking (e.g., dots instead of input characters) of these codes is essential to protect user privacy. This can be achieved by using appropriate input types that obscure the characters entered by the user. In Jetpack Compose, `SecureTextField` uses `TextObfuscationMode`, which [by default is `TextObfuscationMode.RevealLastTyped`](https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/material/material/src/commonMain/kotlin/androidx/compose/material/SecureTextField.kt;l=115?q=SecureTextField), so a developer can simply use `SecureTextField` without explicitly setting `textObfuscationMode` unless another behavior is required.

XML view:

```xml
<EditText
    android:inputType="textPassword"
    ...
/>
```

Jetpack Compose:

```kotlin
SecureTextField(
    // textObfuscationMode defaults to TextObfuscationMode.RevealLastTyped
    textObfuscationMode = TextObfuscationMode.RevealLastTyped, // or TextObfuscationMode.Hidden
    ...
)
```

!!! note
    Even if `SecureTextField` uses the default `TextObfuscationMode.RevealLastTyped` or is configured explicitly with `RevealLastTyped` or `Hidden`, it can later be changed to `Visible` programmatically.

## Steps

1. Use @MASTG-TECH-0013 to reverse engineer the app.
2. Use @MASTG-TECH-0014 to look for references to the text field classes and text obfuscation APIs.
3. Manually evaluate and shortlist the fields for access or verification codes usage.

## Observation

The output should contain a list of locations where text input fields for access or verification codes are used.

## Evaluation

The test case fails if any text input field used for access or verification codes is found to be unmasked. For example, due to the following:

- `TextField` is used
- `SecureTextField` is used but configured with `TextObfuscationMode.Visible`

!!! note
    This test may produce false negatives if the app uses custom text input controls that do not rely on standard classes such as `TextField` or `SecureTextField` (for example in custom UI frameworks or game engines).
OWASP Mobile Application Security Testing Guide: MASTG TEST 0294

---
title: "`SecureOn` Not Used to Prevent Screenshots in Compose Dialogs"
platform: android
id: MASTG-TEST-0294
type: [static]
profiles: [L2]
best-practices: [MASTG-BEST-0014, MASTG-BEST-0018]
weakness: MASWE-0055
knowledge: [MASTG-KNOW-0053]
status: placeholder
note: This test verifies whether an app prevents sensitive data from being captured in screenshots and screen recordings of Jetpack Compose dialogs.
---
OWASP Mobile Application Security Testing Guide: MASTG TEST 0292

---
title: "`setRecentsScreenshotEnabled` Not Used to Prevent Screenshots When Backgrounded"
platform: android
id: MASTG-TEST-0292
type: [static]
profiles: [L2]
best-practices: [MASTG-BEST-0014, MASTG-BEST-0015]
weakness: MASWE-0055
knowledge: [MASTG-KNOW-0053]
status: placeholder
note: This test verifies whether an app prevents sensitive data from being captured in the Recents screen when backgrounded.
---
OWASP Mobile Application Security Testing Guide: MASTG TEST 0289

---
title: Runtime Verification of Sensitive Content Exposure in Screenshots During App Backgrounding
platform: android
id: MASTG-TEST-0289
type: [dynamic, manual]
profiles: [L2]
best-practices: [MASTG-BEST-0014]
weakness: MASWE-0055
prerequisites:
- identify-sensitive-screens
knowledge: [MASTG-KNOW-0053]
---

## Overview

This test verifies that the app hides sensitive content from the screen when it moves to the background. This is important because Android captures a task screenshot of the app UI when it moves to the background. This screenshot is used for the [Recents screen](https://developer.android.com/guide/components/activities/recents) and transitions, and can expose sensitive content if the app does not protect it.

## Steps

1. Exercise your app until you get to each of the screens identified as sensitive. While on each of those screens, move the app to the background (for example by pressing **Home** or opening the **Recents screen** and exiting it) and continue to the next screen.
2. Once finished, use @MASTG-TECH-0002 to copy the screenshot taken by the system to your laptop for further analysis. The system stores the screenshots in their containers `/data/system_ce/0/snapshots` or `/data/system`.

## Observation

The output should include a collection of screenshots cached when the app entered the background state.

## Evaluation

The test case fails if any screenshot displays sensitive data that should have been protected.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0274

---
platform: android
title: Dependencies with Known Vulnerabilities in the App's SBOM
id: MASTG-TEST-0274
type: [static, developer]
weakness: MASWE-0076
profiles: [L1, L2]
---

## Overview

In this test case we are identifying dependencies with known vulnerabilities by relying on a Software Bill of Material (SBOM).

## Steps

1. Either ask the development team to share a SBOM in CycloneDX format, or, if you have access to the original source code, create one following @MASTG-TECH-0130.
2. Upload the SBOM to @MASTG-TOOL-0132.
3. Inspect the @MASTG-TOOL-0132 project for the use of vulnerable dependencies.

## Observation

The output should include a list of dependencies with names and CVE identifiers, if any.

## Evaluation

The test case fails if you can find dependencies with known vulnerabilities.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0337

---
title: References to Object Deserialization of Untrusted Data
platform: android
id: MASTG-TEST-0337
type: [static]
weakness: MASWE-0088
profiles: [L1, L2]
knowledge: [MASTG-KNOW-0021]
---

## Overview

Android apps can reconstruct objects from serialized data received through platform mechanisms such as `Intent` extras, `Bundle` values, IPC payloads, files, or network responses. If the app deserializes data from these sources without restricting the allowed classes or validating the input before use, the deserialization logic can introduce unintended application behavior or unsafe state changes.

This test checks whether the app uses object deserialization on Android and whether the deserialized data originates from potentially untrusted sources without appropriate filtering or validation. For background on Android serialization and deserialization mechanisms, see @MASTG-KNOW-0021.

## Steps

1. Reverse engineer the app (@MASTG-TECH-0013).
2. Run static analysis (@MASTG-TECH-0014) to search for references to object deserialization APIs.

## Observation

The output should contain a list of locations where object deserialization is used.

## Evaluation

The test case fails if the app deserializes data received from untrusted sources (e.g., Intent extras from any other application) without proper validation or type filtering.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0245

---
platform: android
title: References to Platform Version APIs
id: MASTG-TEST-0245
apis: [Build]
type: [static]
weakness: MASWE-0077
best-practices: []
profiles: [L2]
---

## Overview

This test verifies whether an app is running on a recent version of the Android operating system.

In Kotlin, Android apps can determine the OS version using the `Build.VERSION.SDK_INT` property, which returns the API level of the current system. By comparing it to a specific version constant, such as `Build.VERSION_CODES.UPSIDE_DOWN_CAKE` for Android 14 (API level 34), apps can conditionally execute code based on the OS version. In this example, "Upside Down Cake" is the internal codename for Android 14.

Android apps specify a `minSdkVersion`, which defines the oldest OS version they support. While a high `minSdkVersion` reduces the need for runtime version checks, dynamically verifying the OS version using `Build.VERSION.SDK_INT` remains beneficial. It allows apps to take advantage of newer, more secure features when available while maintaining backward compatibility.

## Steps

1. Use either @MASTG-TECH-0014 with a tool such as @MASTG-TOOL-0110 to identify APIs that check the version of the operating system.

## Observation

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

## Evaluation

The test fails if the app does not include any API calls to verify the operating system version.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0272

---
platform: android
title: Identify Dependencies with Known Vulnerabilities in the Android Project
id: MASTG-TEST-0272
type: [static]
weakness: MASWE-0076
profiles: [L1, L2]
---

## Overview

In this test case we will identify dependencies in Android Studio and scan them with @MASTG-TOOL-0131.

## Steps

1. Follow @MASTG-TECH-0131 and execute a scan through the build environment of Android Studio by using Gradle.

## Observation

The output should include the dependency and the CVE identifiers for any dependency with known vulnerabilities.

## Evaluation

The test case fails if you can find dependencies with known vulnerabilities.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0339

---
title: SQL Injection in Content Providers
platform: android
id: MASTG-TEST-0339
type: [static]
weakness: MASWE-0086
best-practices: [MASTG-BEST-0039]
profiles: [L1, L2]
knowledge: [MASTG-KNOW-0117]
---

## Overview

Android applications can share structured data via `ContentProvider` components. However, if these providers create SQL queries using untrusted input from URIs without adequate validation or parameterization, they risk becoming susceptible to SQL injection attacks.

## Steps

1. Reverse engineer the app (@MASTG-TECH-0013).
2. Run static analysis (@MASTG-TECH-0014) to search for unsafe SQL construction in ContentProviders.

## Observation

The output should contain a list of locations where user-controlled input from URIs or selection arguments is concatenated into SQL queries, for example via `Uri.getPathSegments()` and `SQLiteQueryBuilder.appendWhere()`.

## Evaluation

The test case fails if:

- Untrusted user input (e.g., from `getPathSegments()`) is directly concatenated into SQL statements.
- The app uses `appendWhere()` or builds queries unsafely without sanitization or parameterization.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0338

---
title: Integrity and Authenticity Validation of Local Storage Data
platform: android
id: MASTG-TEST-0338
type: [static]
weakness: MASWE-0082
profiles: [L1, L2]
knowledge: [MASTG-KNOW-0036]
---

## Overview

Apps may store sensitive data in local storage and later use it in security-relevant decisions. If that data can be modified by an attacker and the app does not verify its integrity and authenticity before using it, the app may trust tampered input.

This test applies to local storage broadly, including `SharedPreferences`, files, databases, and other app managed storage locations.

For example, when using `SharedPreferences` specifically, the data is stored in the app's private sandbox and normally cannot be modified by other apps. However, it can still be tampered with in local attack scenarios, such as on rooted devices, during dynamic analysis, through backups, or by directly manipulating the app's data directory after obtaining privileged access, as described in @MASTG-KNOW-0036. Because of that, apps should not blindly trust security-relevant data loaded from local storage.

When performing this test, look not only for storage read APIs, but also for nearby integrity and authenticity validation logic. Depending on the implementation, this may include APIs and patterns related to HMACs, MAC comparison, cryptographic initialization, signature verification, checksums, or other mechanisms intended to detect tampering.

## Steps

1. Reverse engineer the app with @MASTG-TECH-0017.
2. Run a static analysis tool with @MASTG-TECH-0014 on the reverse engineered app to identify APIs that read data from local storage and, where possible, related integrity and authenticity validation APIs.

## Observation

The output should contain code locations where the app reads data from local storage. Depending on the storage API and the analysis rule, these code locations may include APIs such as `SharedPreferences.getString`, file reads, database queries, or nearby comparison and verification logic such as HMAC or MAC related operations.

## Evaluation

The test case fails if the app doesn't verify the integrity and authenticity of data loaded from local storage before being used in security-relevant decisions.

This means that the presence of the target APIs, for example `SharedPreferences.getString`, does not inherently fail the test. Each reported code location must be carefully analyzed by reverse engineering it and checking whether the app performs the proper validation.

When evaluating reported code locations, determine:

1. What value is being loaded from local storage.
2. Whether that value can influence a security-relevant decision, such as authentication state, authorization, feature access, configuration, or trust decisions.
3. Whether the app verifies the integrity and authenticity of the loaded value before using it, for example with an HMAC, MAC, signature, or similar verification mechanism.
4. Whether that validation is effective for the attacker model in scope.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0222

---
title: Position Independent Code (PIC) Not Enabled
platform: android
id: MASTG-TEST-0222
deprecated_since: 21
type: [static]
weakness: MASWE-0116
profiles: [L2]
knowledge: [MASTG-KNOW-0006]
---

## Overview

This test case checks if the [native libraries](../../../Document/0x04h-Testing-Code-Quality.md#binary-protection-mechanisms) of the app are compiled without enabling [Position Independent Code (PIC)](../../../Document/0x04h-Testing-Code-Quality.md#position-independent-code), a common mitigation technique against memory corruption attacks.

Since Android 5.0 (API level 21), Android requires [all dynamically linked executables to support PIE](https://source.android.com/docs/security/enhancements/#android-5).

> [Build System Maintainers Guide - Additional Required Arguments](https://android.googlesource.com/platform/ndk/%2B/master/docs/BuildSystemMaintainers.md#additional-required-arguments): Android requires Position-independent executables beginning with API 21. Clang builds PIE executables by default. If invoking the linker directly or not using Clang, use `-pie` when linking.

## Steps

1. Extract the app contents (@MASTG-TECH-0007).
2. Run @MASTG-TECH-0115 on each shared library and grep for "pic" or the corresponding keyword used by the selected tool.

## Observation

The output should list if PIC is enabled or disabled.

## Evaluation

The test case fails if PIC is disabled.