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

---
platform: android
title: References to APIs Detecting Biometric Enrollment Changes
id: MASTG-TEST-0328
apis: [KeyGenParameterSpec.Builder, setInvalidatedByBiometricEnrollment]
type: [static]
weakness: MASWE-0046
profiles: [L2]
knowledge: [MASTG-KNOW-0001]
best-practices: [MASTG-BEST-0037]
---

## Overview

This test checks whether the app fails to protect sensitive operations against unauthorized access following biometric enrollment changes (@MASTG-KNOW-0001). An attacker who obtains the device passcode could add a new fingerprint or facial representation via system settings and use it to authenticate in the app.

This behaviour occurs when [`setInvalidatedByBiometricEnrollment`](https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder#setInvalidatedByBiometricEnrollment(boolean)) is set to `false` when keys are generated.

By default and when set to `true`, a key becomes permanently invalidated if a new biometric is enrolled. As a result, only users whose biometric data was enrolled when the item was created can unlock it. This prevents unauthorized access through biometrics enrolled later.

## 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 fails if the app uses `setInvalidatedByBiometricEnrollment(false)` for keys used to protect sensitive data resources.

The test passes if the app either:

- uses `setInvalidatedByBiometricEnrollment(true)` explicitly, or
- relies on the default behavior, which invalidates keys on new biometric enrollment when `setUserAuthenticationRequired(true)` is set.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0329

---
platform: android
title: References to APIs Enforcing Authentication without Explicit User Action
id: MASTG-TEST-0329
apis: [BiometricPrompt.PromptInfo.Builder, setConfirmationRequired]
type: [static]
weakness: MASWE-0044
profiles: [L2]
knowledge: [MASTG-KNOW-0001]
best-practices: [MASTG-BEST-0038]
---

## Overview

This test checks if the app enforces biometric authentication (@MASTG-KNOW-0001) [without requiring explicit user action](https://developer.android.com/identity/sign-in/biometric-auth#no-explicit-user-action). When using [`android.hardware.biometrics.BiometricPrompt`](https://developer.android.com/reference/android/hardware/biometrics/BiometricPrompt) API (or its Jetpack counterpart [`androidx.biometric.BiometricPrompt`](https://developer.android.com/reference/androidx/biometric/BiometricPrompt) that backward compatibility to API level 23), the [`setConfirmationRequired()`](https://developer.android.com/reference/android/hardware/biometrics/BiometricPrompt.Builder#setConfirmationRequired(boolean)) method in [`BiometricPrompt.Builder`](https://developer.android.com/reference/android/hardware/biometrics/BiometricPrompt.Builder) controls whether the user must explicitly confirm their authentication, which is enforced by default.

## 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 fails if the app sets `setConfirmationRequired()` to `false` for sensitive operations that require explicit user authorization.

The test passes if the app either:

- Sets `setConfirmationRequired()` to `true` explicitly for sensitive operations, or
- Relies on the default behavior, which requires confirmation.

!!! note
    Using [`setConfirmationRequired(false)`](https://developer.android.com/identity/sign-in/biometric-auth#no-explicit-user-action) is not inherently a vulnerability. It may be appropriate for low-risk operations, but for sensitive operations like payments or data access, the app should use `setConfirmationRequired(true)` or rely on the default behavior to [ensure the user explicitly confirms the authentication](https://developer.android.com/identity/sign-in/biometric-auth#no-explicit-user-action).
OWASP Mobile Application Security Testing Guide: MASTG TEST 0330

---
platform: android
title: References to APIs for Keys used in Biometric Authentication with Extended Validity Duration
id: MASTG-TEST-0330
apis: [KeyGenParameterSpec.Builder, setUserAuthenticationParameters, setUserAuthenticationValidityDurationSeconds]
type: [static]
weakness: MASWE-0044
profiles: [L2]
knowledge: [MASTG-KNOW-0001, MASTG-KNOW-0043, MASTG-KNOW-0047, MASTG-KNOW-0012]
best-practices: [MASTG-BEST-0036]
---

## Overview

This test checks if the app configures cryptographic keys with an extended validity duration that allows keys to remain unlocked beyond the immediate operation. When using biometric authentication with [`CryptoObject`](https://developer.android.com/reference/androidx/biometric/BiometricPrompt.CryptoObject), the authentication validity duration determines how long a key remains usable after successful authentication.

On Android, developers can configure this behavior using [`setUserAuthenticationParameters(int timeout, int type)`](https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder#setUserAuthenticationParameters(int,%20int)) or the deprecated [`setUserAuthenticationValidityDurationSeconds(int)`](https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder#setUserAuthenticationValidityDurationSeconds(int)) when generating keys with [`KeyGenParameterSpec.Builder`](https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder):

- **Duration = 0**: The key requires authentication for every cryptographic operation. This is the most secure configuration as each use of the key requires biometric verification.
- **Duration > 0**: The key remains unlocked for the specified duration (in seconds) after successful authentication. When the duration is set to a high value in the range of minutes or hours an attacker with physical access to the phone could trigger sensitive operations without biometric verification.

## 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 fails if the app configures keys used for sensitive operations with:

- `setUserAuthenticationParameters(duration, type)` where duration > 0
- `setUserAuthenticationValidityDurationSeconds(duration)` where duration > 0

The test passes if the app uses `setUserAuthenticationParameters(0, type)` to require authentication for every cryptographic operation when protecting sensitive data resources or sensitive functionality.

!!! note
    A non-zero authentication validity duration is not inherently a vulnerability. Short durations in the range of seconds may be acceptable for certain use cases where multiple related operations need to be performed in quick succession. However, for high-security applications and sensitive operations, requiring authentication per use (duration = 0) provides the strongest protection against unauthorized key usage and runtime attacks.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0326

---
platform: android
title: References to APIs Allowing Fallback to Non-Biometric Authentication
id: MASTG-TEST-0326
apis: [BiometricPrompt, BiometricManager.Authenticators, setAllowedAuthenticators]
type: [static]
weakness: MASWE-0045
profiles: [L2]
knowledge: [MASTG-KNOW-0001]
best-practices: [MASTG-BEST-0031]
---

## Overview

This test checks if the app uses biometric authentication mechanisms (@MASTG-KNOW-0001) that allow fallback to device credentials (PIN, pattern, or password) for sensitive operations.

On Android, the [`android.hardware.biometrics.BiometricPrompt`](https://developer.android.com/reference/android/hardware/biometrics/BiometricPrompt) API (or its Jetpack counterpart [`androidx.biometric.BiometricPrompt`](https://developer.android.com/reference/androidx/biometric/BiometricPrompt) that backward compatibility to API level 23) can be configured to accept different types of [`BiometricManager.Authenticators`](https://developer.android.com/reference/android/hardware/biometrics/BiometricManager.Authenticators#constants_1) via the [`setAllowedAuthenticators`](https://developer.android.com/reference/android/hardware/biometrics/BiometricPrompt.Builder#setAllowedAuthenticators(int)) method.

When the authenticator constant `DEVICE_CREDENTIAL` is included (either alone or combined with biometric authenticators using the `OR` operator "`|`"), the authentication allows fallback to device credentials, which is considered weaker than requiring biometrics alone because passcodes are more susceptible to compromise (e.g., through [shoulder surfing](https://en.wikipedia.org/wiki/Shoulder_surfing_%28computer_security%29)).

Similarly, using [`setDeviceCredentialAllowed(true)`](https://developer.android.com/reference/android/hardware/biometrics/BiometricPrompt.Builder#setDeviceCredentialAllowed(boolean)) (deprecated since API 30) also enables fallback to device credentials.

## 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 fails if the app uses `BiometricPrompt` with authenticators that include `DEVICE_CREDENTIAL` for any sensitive data resource that needs protection.

The test passes if the app uses only `BiometricPrompt` with `BIOMETRIC_STRONG` to enforce biometric-only access for any sensitive data resource that needs protection.

!!! note
    Using `DEVICE_CREDENTIAL` is not inherently a vulnerability, but in high-security applications (e.g., finance, government, health), their use can represent a weakness or misconfiguration that reduces the intended security posture. This issue is therefore better categorized as a security weakness or hardening issue, not a critical vulnerability.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0200

---
platform: android
title: Files Written to External Storage
id: MASTG-TEST-0200
type: [dynamic]
weakness: MASWE-0007
profiles: [L1, L2]
---

## Overview

The goal of this test is to retrieve the files written to the external storage (@MASTG-KNOW-0042) and inspect them regardless of the APIs used to write them. It uses a simple approach based on file retrieval from the device storage (@MASTG-TECH-0002) before and after the app is exercised to identify the files created during the app's execution and to check if they contain sensitive data.

## Steps

1. Make sure you have @MASTG-TOOL-0004 installed.
2. Install the app (@MASTG-TECH-0005).
3. Before running the app, get the current list of files (@MASTG-TECH-0002) in the external storage.
4. Exercise the app.
5. After running the app, retrieve the list of files in the external storage again.
6. Calculate the difference between the two lists.

## Observation

The output should contain a list of files that were created on the external storage during the app's execution.

## Evaluation

The test case fails if the files found above are not encrypted and leak sensitive data.

To confirm this, you can reverse engineer the app(@MASTG-TECH-0017) and inspect the code(@MASTG-TECH-0023).
OWASP Mobile Application Security Testing Guide: MASTG TEST 0201

---
platform: android
title: Runtime Use of APIs to Access External Storage
id: MASTG-TEST-0201
apis: [Environment#getExternalStorageDirectory, Environment#getExternalStorageDirectory, Environment#getExternalFilesDir, Environment#getExternalCacheDir, FileOutputStream]
type: [dynamic]
weakness: MASWE-0007
profiles: [L1, L2]
knowledge: [MASTG-KNOW-0042]
---

## Overview

Android apps use a variety of APIs to access the external storage (@MASTG-KNOW-0042). Collecting a comprehensive list of these APIs can be challenging, especially if an app uses a third-party framework, loads code at runtime, or includes native code. The most effective approach to testing applications that write to device storage is usually dynamic analysis, and specifically method tracing (@MASTG-TECH-0033).

## Steps

1. Make sure you have @MASTG-TOOL-0001 installed.
2. Install the app.
3. Execute a script to spawn the app with Frida and log all interactions with files.
4. Navigate to the screen of the app that you want to analyse.
5. Close the app to stop Frida.

The Frida script should log all file interactions by hooking into the relevant APIs such as `getExternalStorageDirectory`, `getExternalStoragePublicDirectory`, `getExternalFilesDir` or `FileOutPutStream`. You could also use `open` as a catch-all for file interactions. However, this won't catch all file interactions, such as those that use the `MediaStore` API and should be done with additional filtering as it can generate a lot of noise.

## Observation

The output should contain a list of files that the app wrote to the external storage during execution and, if possible, the APIs used to write them.

## Evaluation

The test case fails if the files found above are not encrypted and leak sensitive data.

To confirm this, you can manually inspect the files using adb shell (@MASTG-TECH-0002) to retrieve them from the device, and reverse engineer the app (@MASTG-TECH-0017) and inspect the code (@MASTG-TECH-0023).
OWASP Mobile Application Security Testing Guide: MASTG TEST 0203

---
platform: android
title: Runtime Use of Logging APIs
id: MASTG-TEST-0203
apis: [Log, Logger, System.out.print, System.err.print, java.lang.Throwable#printStackTrace]
type: [dynamic]
weakness: MASWE-0001
best-practices: [MASTG-BEST-0002]
profiles: [L1, L2, P]
knowledge: [MASTG-KNOW-0049]
---

## Overview

On Android platforms, logging APIs like `Log`, `Logger`, `System.out.print`, `System.err.print`, and `java.lang.Throwable#printStackTrace` can inadvertently lead to the leakage of sensitive information. Log messages are recorded in logcat, a shared memory buffer, accessible since Android 4.1 (API level 16) only to privileged system applications that declare the `READ_LOGS` permission. Nonetheless, the vast ecosystem of Android devices includes pre-loaded apps with the `READ_LOGS` privilege, increasing the risk of sensitive data exposure. Therefore, direct logging to logcat is generally advised against due to its susceptibility to data leaks.

## Steps

1. Install and run the app.
2. Navigate to the screen of the mobile app you want to analyse the log output from.
3. Execute a method trace (@MASTG-TECH-0033) (using e.g. @MASTG-TOOL-0001) by attaching to the running app, targeting logging APIs and save the output.

## Observation

The output should contain a list of locations where logging APIs are used in the app for the current execution.

## Evaluation

The test case fails if you can find sensitive data being logged using those APIs.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0207

---
platform: android
title: Runtime Storage of Unencrypted Data in the App Sandbox
id: MASTG-TEST-0207
type: [dynamic, filesystem]
prerequisites:
- identify-sensitive-data
weakness: MASWE-0006
profiles: [L2]
knowledge: [MASTG-KNOW-0041]
---

## Overview

The goal of this test is to retrieve the files written to the internal storage (@MASTG-KNOW-0041) and inspect them regardless of the APIs used to write them. It uses a simple approach based on file retrieval from the device storage (@MASTG-TECH-0002) before and after the app is exercised to identify the files created during the app's execution and to check if they contain sensitive data.

## Steps

1. Start the device.

2. Take a first copy of the app's private data directory (@MASTG-TECH-0008) to have as a reference for offline analysis. You can use @MASTG-TOOL-0004 for example.

3. Launch and use the app going through the various workflows while inputting sensitive data wherever you can. Taking note of the data you input can help identify it later using tools to search for it.

4. Take a second copy of the app's private data directory for offline analysis and make a diff using the first copy to identify all files created or modify during your testing session.

## Observation

The output should contain a list of files that were created in the app's private storage during execution.

## Evaluation

Attempt to identify and decode data that has been encoded using methods such as base64 encoding, hexadecimal representation, URL encoding, escape sequences, wide characters and common data obfuscation methods such as xoring. Also consider identifying and decompressing compressed files such as tar or zip. These methods obscure but do not protect sensitive data.

Search the extracted data for items such as keys, passwords and any sensitive data inputted into the app. The test case fails if you find any of this sensitive data.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0231

---
platform: android
title: References to Logging APIs
id: MASTG-TEST-0231
apis: [Log, Logger, System.out.print, System.err.print, java.lang.Throwable#printStackTrace, android.util.Log]
type: [static]
weakness: MASWE-0001
best-practices: [MASTG-BEST-0002]
profiles: [L1, L2, P]
knowledge: [MASTG-KNOW-0049]
---

## Overview

This test verifies if an app uses logging APIs like `android.util.Log`, `Log`, `Logger`, `System.out.print`, `System.err.print`, and `java.lang.Throwable#printStackTrace`.

## Steps

1. Use either @MASTG-TECH-0014 with a tool such as @MASTG-TOOL-0110 to identify all logging APIs.

## Observation

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

## Evaluation

The test fails if an app logs sensitive information from any of the listed locations.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0306

---
title: Sensitive Data Stored Unencrypted via Android Room DB 
platform: android
id: MASTG-TEST-0306
type: [static, dynamic]
weakness: MASWE-0006
best-practices: []
profiles: [L1, L2]
status: placeholder
note: This test checks if the app uses the Android Room Persistence Library to store sensitive data (e.g., tokens, PII) without integrating an encryption layer (e.g., SQLCipher). It confirms the database file is stored in plaintext within the app's private sandbox.
---
OWASP Mobile Application Security Testing Guide: MASTG TEST 0304

---
title: Sensitive Data Stored Unencrypted via SQLite 
platform: android
id: MASTG-TEST-0304
type: [static, dynamic]
weakness: MASWE-0006
best-practices: []
profiles: [L1, L2]
knowledge: [MASTG-KNOW-0037]
status: placeholder
note: This test checks if the app uses the default SQLite API (e.g., `SQLiteOpenHelper`, `context.openOrCreateDatabase`) to store sensitive data (e.g., tokens, PII) in an unencrypted database file within the app's sandbox. It confirms the absence of secure alternatives like SQLCipher or encrypted databases.
---
OWASP Mobile Application Security Testing Guide: MASTG TEST 0216

---
platform: android
title: Sensitive Data Not Excluded From Backup
id: MASTG-TEST-0216
type: [dynamic, filesystem]
weakness: MASWE-0004
best-practices: [MASTG-BEST-0004]
profiles: [L1, L2, P]
knowledge: [MASTG-KNOW-0050]
---

## Overview

This test verifies whether apps correctly instruct the system to exclude sensitive files from backups by performing a backup and restore of the app data and checking which files are restored.

See @MASTG-TEST-0262 for a static analysis counterpart.

Android provides a way to start the backup daemon to back up and restore app files, which you can use to verify which files are actually restored from the backup.

## Steps

1. Start the device.
2. Install an app on your device.
3. Launch and use the app going through the various workflows while inputting sensitive data wherever you can.
4. Perform a backup and restore of the app data (@MASTG-TECH-0128).
5. Uninstall and reinstall the app but don't open it anymore.
6. Restore the data from the backup and get the list of restored files.

## Observation

The output should contain a list of files that are restored from the backup.

## Evaluation

The test fails if any of the files are considered sensitive.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0202

---
platform: android
title: References to APIs and Permissions for Accessing External Storage
id: MASTG-TEST-0202
apis: [Environment#getExternalStoragePublicDirectory, Environment#getExternalStorageDirectory, Environment#getExternalFilesDir, Environment#getExternalCacheDir, MediaStore, WRITE_EXTERNAL_STORAGE, MANAGE_EXTERNAL_STORAGE]
type: [static]
weakness: MASWE-0007
profiles: [L1, L2]
knowledge: [MASTG-KNOW-0042]
---

## Overview

This test uses static analysis to look for uses of APIs allowing an app to write to locations that are shared with other apps (@MASTG-TEST-0001) such as the External Storage APIs or the `MediaStore` API as well as the relevant Android manifest storage-related permissions. Refer to @MASTG-KNOW-0042 for more information.

This static test is great for identifying all code locations where the app is writing data to shared storage. However, it does not provide the actual data being written, and in some cases, the actual path in the device storage where the data is being written. Therefore, it is recommended to combine this test with others that take a dynamic approach, as this will provide a more complete view of the data being written to shared storage.

## 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 any external storage APIs and Android manifest storage permissions.

The static analysis tool should be able to identify all possible APIs and permissions used to write to shared storage, such as `getExternalStoragePublicDirectory`, `getExternalStorageDirectory`, `getExternalFilesDir`, `MediaStore`, `WRITE_EXTERNAL_STORAGE`, and `MANAGE_EXTERNAL_STORAGE`. See the [Android documentation](https://developer.android.com/training/data-storage/shared) for more information on these APIs and permissions.

## Observation

The output should contain a list of APIs and storage-related permissions used to write to shared storage and their code locations.

## Evaluation

The test case fails if:

- the app has the proper permissions declared in the Android manifest (e.g. `WRITE_EXTERNAL_STORAGE`, `MANAGE_EXTERNAL_STORAGE`, etc.)
- **and** the data being written to shared storage is sensitive and not encrypted.

To determine the latter, you may need to carefully review the reversed code (@MASTG-TECH-0023) and/or combine this test with others that take a dynamic approach, as this will provide a more complete view of the data being written to shared storage.

## References

- [Manage all files on a storage device](https://developer.android.com/training/data-storage/manage-all-files)
- [Access media files from shared storage](https://developer.android.com/training/data-storage/shared/media)
OWASP Mobile Application Security Testing Guide: MASTG TEST 0287

---
title: Sensitive Data Stored Unencrypted via the SharedPreferences API to the App Sandbox
platform: android
id: MASTG-TEST-0287
type: [static, dynamic]
weakness: MASWE-0006
best-practices: []
profiles: [L1, L2]
knowledge: [MASTG-KNOW-0036]
status: placeholder
note: This test checks if the app is using the SharedPreferences API to store sensitive data (e.g. user credentials, tokens) in an unencrypted format within the app's sandbox. This includes checking for the use of `SharedPreferences` without encryption as well as not using `EncryptedSharedPreferences` or similar secure storage mechanisms.
---
OWASP Mobile Application Security Testing Guide: MASTG TEST 0305

---
title: Sensitive Data Stored Unencrypted via DataStore 
platform: android
id: MASTG-TEST-0305
type: [static, dynamic]
weakness: MASWE-0006
best-practices: []
profiles: [L1, L2]
status: placeholder
note: This test checks if the app uses the modern Jetpack DataStore API (Preferences DataStore or Proto DataStore) to store sensitive data (e.g., tokens, PII) without encryption. It confirms the absence of secure serializers or mechanisms to protect data integrity and confidentiality.
---