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

---
platform: ios
title: Runtime Monitoring of Text Fields Eligible for Keyboard Caching
id: MASTG-TEST-0314
type: [dynamic]
weakness: MASWE-0053
profiles: [L2]
prerequisites:
- identify-sensitive-data
best-practices: [MASTG-BEST-0026]
knowledge: [MASTG-KNOW-0100]
---

## Overview

This test complements @MASTG-TEST-0313. It monitors text inputs in the app at runtime, for example [`UITextField`](https://developer.apple.com/documentation/uikit/uitextfield), [`UITextView`](https://developer.apple.com/documentation/uikit/uitextview) or [`UISearchBar`](https://developer.apple.com/documentation/uikit/uisearchbar), and checks whether they are eligible for keyboard caching when the user enters sensitive information.

## Steps

1. Use @MASTG-TECH-0056 to install the app.
2. Use @MASTG-TECH-0067 to look for text input fields in the app's UI and identify those that use the relevant attributes.
3. Exercise the app thoroughly, entering realistic sensitive information (for example, usernames, passwords, email addresses, credit card numbers, recovery codes) into each identified input field.

## Observation

The output should allow the tester to associate each text entry with the corresponding input field and its protection status. At minimum it should contain:

- The input widget details, including class and accessibility identifier when available.
- The input traits relevant to keyboard caching, for example: `isSecureTextEntry`, `autocorrectionType`, `spellCheckingType`, and any other traits or flags that influence keyboard prediction or caching.
- The entered values so they can be correlated with sensitive information.

## Evaluation

The test fails if any UI inputs that may handle sensitive values (for example, usernames, passwords, email addresses, credit card numbers, recovery codes) are eligible for keyboard caching. This occurs when:

- `isSecureTextEntry` is not enabled, or
- `autocorrectionType` is set to `default` or `yes`, or
- `spellCheckingType` is set to `default` or `yes`.

The test passes if all security-sensitive inputs are protected against keyboard caching.

**Note:** This test may produce false negatives if the app uses custom text input controls that do not rely on standard UIKit classes such as `UITextField` or `UITextView` (for example in custom UI frameworks or game engines), or if text entry is handled through nonstandard abstractions that prevent reliable observation of input traits at runtime.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0303

---
platform: ios
title: References to APIs for Storing Unencrypted Data in Shared Storage
id: MASTG-TEST-0303
type: [static]
profiles: [L1, L2]
best-practices: [MASTG-BEST-0024]
weakness: MASWE-0007
knowledge: [MASTG-KNOW-0091, MASTG-KNOW-0057, MASTG-KNOW-0108]
---

## Overview

This test checks whether the app writes sensitive data unencrypted to storage locations in the app sandbox that are configured for sharing by enabling file sharing in the app's Info.plist using the `UIFileSharingEnabled` ("Application supports iTunes file sharing") and `LSSupportsOpeningDocumentsInPlace` ("Supports opening documents in place") keys set to `YES`.

## Steps

1. Run a static analysis tool such as @MASTG-TOOL-0073 on the app binary.

2. Search for APIs that indicate use of shared storage, for example:

      - [`documentDirectory`](https://developer.apple.com/documentation/foundation/filemanager/searchpathdirectory/documentdirectory) (commonly exposed via iTunes File Sharing / Files app)
      - `FileManager.default.urls(for:in:)` with `documentDirectory`
      - Direct path manipulation under `.../Documents` for write operations (`Data.write(to:)`, `String.write(to:)`, `NSFileHandle`, `NSOutputStream`)

3. Check the app's `Info.plist` (@MASTG-TECH-0058) for the `UIFileSharingEnabled` and `LSSupportsOpeningDocumentsInPlace` flags.

## Observation

The output should contain:

- A list of code locations that write (or could write) to shared storage.
- The state of `UIFileSharingEnabled` and `LSSupportsOpeningDocumentsInPlace`.

## Evaluation

The test fails if:

- The app writes unencrypted sensitive data to `documentDirectory` (or equivalent shared storage path), and
- `Info.plist` enables user access to the Documents directory (`UIFileSharingEnabled` and/or `LSSupportsOpeningDocumentsInPlace`).

Note: `documentDirectory` by itself is not inherently insecure; the risk arises when sensitive data is stored there and exposed via file sharing or Files app access. In contrast, data stored in other locations within the app sandbox (e.g., `Library/Application Support`) with encryption, or in the Keychain cannot be accessed even if file sharing is enabled.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0313

---
platform: ios
title: References to APIs for Preventing Keyboard Caching of Text Fields
id: MASTG-TEST-0313
type: [static]
weakness: MASWE-0053
profiles: [L2]
best-practices: [MASTG-BEST-0026]
knowledge: [MASTG-KNOW-0100]
---

## Overview

This test verifies whether the target app prevents sensitive information entered into text fields from being cached by the system keyboard. On iOS, the keyboard may suggest previously entered text when typing in any app on the device.

The test checks whether UI elements such as `UITextField`, `UITextView`, and `UISearchBar` prevent keyboard caching by using one or more of the following attributes:

- Setting [`UITextAutocorrectionType`](https://developer.apple.com/documentation/uikit/uitextautocorrectiontype)
- Enabling [`isSecureTextEntry`](https://developer.apple.com/documentation/uikit/uitextinputtraits/issecuretextentry)
- Setting [`spellCheckingType`](https://developer.apple.com/documentation/uikit/uitextinputtraits/spellcheckingtype)

**Note:** By default, text input is eligible for keyboard caching, and an app does not need to explicitly set `UITextAutocorrectionType` when creating a text field. Additionally, the UI may be configured in a Storyboard. As a result, this test may miss many true positives. For complete coverage, using @MASTG-TEST-0314 is recommended.

**Note:** This test may produce false negatives if the app uses custom text input controls that do not rely on standard UIKit classes such as `UITextField` or `UITextView`, for example in custom UI frameworks or game engines, or if text entry is handled through nonstandard abstractions that prevent reliable observation of input traits at rest.

## Steps

1. Use @MASTG-TECH-0065 to reverse engineer the app.
2. Use @MASTG-TECH-0072 to look for references to APIs that set the relevant input attributes.
3. Use @MASTG-TECH-0076 to analyze the relevant code paths and determine the values assigned to these attributes.

## Observation

The output should contain a list of locations where the app:

- creates text input fields such as `UITextField`, `UITextView`, or `UISearchBar`, and
- explicitly configures input attributes that prevent keyboard caching for security sensitive text fields.

## Evaluation

The test fails if any UI inputs that may handle sensitive values, for example usernames, passwords, email addresses, credit card numbers, or recovery codes, are eligible for keyboard caching. This occurs when:

- `isSecureTextEntry` is not enabled, or
- `autocorrectionType` is set to `default` or `yes`, or
- `spellCheckingType` is set to `default` or `yes`.

The test passes if all security-sensitive inputs are protected against keyboard caching.

**Note:** Depending on the app's threat model, some text fields may not require disabling spell checking. However, since enabling `isSecureTextEntry` implicitly disables both autocorrection and spell checking, and since explicit guarantees are otherwise limited, it is generally advisable to disable all three attributes for any text field that may handle sensitive information.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0298

---
platform: ios
title: Runtime Monitoring of Files Eligible for Backup
id: MASTG-TEST-0298
type: [dynamic]
weakness: MASWE-0004
best-practices: [MASTG-BEST-0023]
profiles: [L1, L2, P]
knowledge: [MASTG-KNOW-0102]
---

## Overview

This test logs every file written to the app's data container at `/var/mobile/Containers/Data/Application/$APP_ID` to identify which files are eligible for backup. Files stored in the `tmp` or `Library/Caches` subdirectories are not logged, as they are not backed up.

## Steps

1. Use runtime method hooking (see @MASTG-TECH-0095) and look for uses of file system APIs such as `open`, `fopen`, `NSFileManager`, or `FileHandle` that create or write files.
2. Exercise the app to trigger file creation and writing.

## Observation

The output should list every file the app opens that is eligible for backup.

## Evaluation

The test case fails if any sensitive files are found in the output.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0299

---
platform: ios
title: Data Protection Classes for Files in Private Storage
id: MASTG-TEST-0299
type: [dynamic, filesystem]
prerequisites:
- identify-sensitive-data
profiles: [L1]
weakness: MASWE-0006
best-practices: [MASTG-BEST-0024]
knowledge: [MASTG-KNOW-0091, MASTG-KNOW-0108]
---

## Overview

This test retrieves the data protection classes of files created or modified in the app's private storage during typical app usage. The goal is to ensure that files containing sensitive data are assigned appropriate data protection classes to safeguard them when the device is locked.

## Steps

1. Ensure the device / simulator is in a clean state (no prior test artifacts). Terminate the app if running.
2. Launch and exercise the app to trigger typical workflows (authentication, profile loading, messaging, caching, offline usage, cryptographic operations).
3. Retrieve the list of files from the app's private storage (sandbox) directory tree (`/var/mobile/Containers/Data/Application/<UUID>/`) including the data protection classes (@MASTG-TECH-0059).

## Observation

The output should contain:

- List of files in private storage including at least path and data protection class.

## Evaluation

The test case fails if **files containing sensitive data** have the data protection class set to `NSFileProtectionNone`.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0281

---
platform: ios
title: Undeclared Known Tracking Domains
id: MASTG-TEST-0281
type: [static, dynamic]
weakness: MASWE-0108
profiles: [P]
---

## Overview

This test identifies whether the app properly declares all known tracking domains it may communicate with in the [`NSPrivacyTrackingDomains`](https://developer.apple.com/documentation/bundleresources/app-privacy-configuration/nsprivacytrackingdomains) section of its [Privacy Manifest](https://developer.apple.com/documentation/bundleresources/privacy_manifest_files) files.

To perform this test, use one or more curated lists of known trackers. These lists include domains and identifiers associated with advertising networks, analytics providers, and user profiling services. They are commonly used in privacy-focused tools and browsers to detect and block tracking behavior.

Some example lists:

- **[DuckDuckGo iOS Trackers](https://github.com/duckduckgo/tracker-blocklists/blob/main/web/v5/ios-tds.json)**: Includes domains, matching rules, descriptions, and categories such as "Action Pixels," "Ad Fraud," "Ad Motivated Tracking," and "Advertising."
- **[Exodus Privacy Trackers](https://reports.exodus-privacy.eu.org/en/trackers/)**: Includes tracker names, categories (e.g., "Advertisement," "Analytics," "Profiling"), descriptions, and detection metadata such as network and code signatures.

These references can be used to match hardcoded or dynamically accessed domains within your app and verify whether appropriate declarations exist in the Privacy Manifest.

## Steps

1. Extract the app's privacy manifest files, including those from third-party SDKs or frameworks using @MASTG-TECH-0136.
2. Obtain the list of declared tracking domains from the privacy manifest files using @MASTG-TECH-0137.
3. Run a static analysis scan using @MASTG-TOOL-0073:
    - Search for hardcoded references to known tracking domains.
    - Identify code references to well-known tracking libraries.
4. Perform network analysis with @MASTG-TOOL-0097:
    - Intercept and log all outbound network traffic.
    - Extract all domain names contacted during runtime.

## Observation

The output should contain:

- All extracted privacy manifests from the app.
- A list of declared tracking domains from the `NSPrivacyTrackingDomains` key in the manifests (preferably with associated components).
- A list of all domains contacted during dynamic testing.
- A list of code matches for known tracking domains or tracking libraries from static analysis.

## Evaluation

The test fails if any of the following is missing in the privacy manifest files' `NSPrivacyTrackingDomains` key for the app or any of its components (Frameworks, Plugins, etc.):

- Tracking domains contacted by the app at runtime.
- Tracking domains found in the code.
- Domains corresponding to tracking SDKs found in the code.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0214

---
title: Hardcoded Cryptographic Keys in Files
platform: ios
id: MASTG-TEST-0214
type: [static]
weakness: MASWE-0014
profiles: [L1, L2]
---

## Overview

Cryptographic keys may be embedded files such as configuration files or key files, certificate files, or other resource files bundled with the app, making them accessible to anyone who can extract the app's resources. Real-world cases include storing API keys, SSL/TLS private keys, or encryption keys within these files, which can lead to serious security vulnerabilities if the app is reverse-engineered.

- **Identified by File Extension**: Files with extensions such as `.key`, `.pem`, `.crt`, `.p12`, `.cer`, or `.der` often contain cryptographic keys or certificates.
- **Identified by PEM Markers**: Strings such as `[CREDENTIAL_REDACTED]`, `-----BEGIN CERTIFICATE-----`, or the byte sequence `0x2d 0x2d 0x2d 0x2d 0x2d` (representing `-----` in ASCII) within files indicate the presence of PEM-encoded keys or certificates.
- **Identified by Common Byte Patterns**: Binary files containing specific byte sequences that match known DER or PKCS#12 formats, such as `0x30 0x82` (indicating the start of a DER-encoded structure), can indicate the presence of cryptographic material.
- **Embedded in Property Lists or JSON Files**: Keys might be stored within `.plist` or `.json` configuration files, often encoded as Base64 strings.
- **Identified by Specific Strings**: Keywords such as `privateKey`, `key`, or `secret` within files or variable names can indicate embedded keys or sensitive data.

## Steps

1. Run a static analysis tool such as @MASTG-TOOL-0073 on the app binary looking for strings or sequences of bytes as indicated above.

## Observation

The output should include any instances where potential cryptographic keys are found hardcoded within the application's source code or binary.

## Evaluation

The test fails if hardcoded cryptographic keys are found within the source code or binary.

Ensure that any identified keys are indeed cryptographic keys used for security-relevant purposes. Avoid false positives by verifying the key's usage context (e.g., configuration settings or non-security-related constants might be misidentified as cryptographic keys).
OWASP Mobile Application Security Testing Guide: MASTG TEST 0211

---
platform: ios
title: Broken Hashing Algorithms
id: MASTG-TEST-0211
type: [static, dynamic]
weakness: MASWE-0021
profiles: [L1, L2]
---

## Overview

To test for the use of broken hashing algorithms in iOS apps, we need to focus on methods from cryptographic frameworks and libraries that are used to perform hashing operations.

- **CommonCrypto**: [CommonDigest.h](https://web.archive.org/web/[PII_REDACTED]0312/https://opensource.apple.com/source/CommonCrypto/CommonCrypto-36064/CommonCrypto/CommonDigest.h) defines the following **hashing algorithms**:
    - `CC_MD2`
    - `CC_MD4`
    - `CC_MD5`
    - `CC_SHA1`
    - `CC_SHA224`
    - `CC_SHA256`
    - `CC_SHA384`
    - `CC_SHA512`

- **CryptoKit**: Supports three cryptographically secure **hashing algorithms** and two insecure ones in a dedicated class called [`Insecure`](https://developer.apple.com/documentation/cryptokit/insecure):
    - `SHA256`
    - `SHA384`
    - `SHA512`
    - `Insecure.MD5`
    - `Insecure.SHA1`

Note: the **Security** framework only supports asymmetric algorithms and is therefore out of scope for this test.

## Steps

1. Run a static analysis tool such as @MASTG-TOOL-0073 on the app binary, or use a dynamic analysis tool like @MASTG-TOOL-0039, and look for uses of the cryptographic functions that perform hashing operations.

## Observation

The output should contain the disassembled code of the functions using the relevant cryptographic functions.

## Evaluation

The test case fails if you can find the use of broken hashing algorithms within the source code. For example:

- MD5
- SHA-1

**Stay up-to-date**: This is a non-exhaustive list of broken algorithms. Make sure to check the latest standards and recommendations from organizations such as the National Institute of Standards and Technology (NIST), the German Federal Office for Information Security (BSI) or any other relevant authority in your region. This is important when building an app that uses data that will be stored for a long time. Make sure you follow the NIST recommendations from [NIST IR 8547 "Transition to Post-Quantum Cryptography Standards", 2024](https://csrc.nist.gov/pubs/ir/8547/ipd).

**Context Considerations**:

To reduce false positives, make sure you understand the context in which the algorithm 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.

For example, using the broken algorithm MD5 for hashing passwords is disallowed by NIST, as it is no longer considered secure for cryptographic purposes. However, using MD5 for checksums or other non-cryptographic tasks, where security is not a concern, is generally acceptable.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0209

---
platform: ios
title: Insufficient Key Sizes
id: MASTG-TEST-0209
type: [static, dynamic]
weakness: MASWE-0009
profiles: [L1, L2]
---

## Overview

In this test case, we will look for the use insufficient key sizes in iOS apps. To do this, we need to focus on the cryptographic frameworks and libraries that are available in iOS and the methods that are used to generate cryptographic keys.

- **CommonCrypto**: The [`CCCrypt`](https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/CCCrypt.3cc.html) function is used for symmetric encryption and decryption and specifies the key size or key length in its fifth parameter `keyLength`.
- **Security**: The [`SecKeyCreateRandomKey`](https://developer.apple.com/documentation/security/1823694-seckeycreaterandomkey) function is used to generate a random key using certain attributes including [`kSecAttrKeyType`](https://developer.apple.com/documentation/security/ksecattrkeytype) and [`kSecAttrKeySizeInBits`](https://developer.apple.com/documentation/security/ksecattrkeysizeinbits). The [`SecKeyGeneratePair`](https://developer.apple.com/documentation/security/1395339-seckeygeneratepair) function is deprecated in iOS 16.
- **CryptoKit**: The [`AES.GCM`](https://developer.apple.com/documentation/cryptokit/aes/gcm) and [`ChaChaPoly`](https://developer.apple.com/documentation/cryptokit/chachapoly) classes are used for symmetric encryption and decryption.

Since you don't usually generate keys directly in CryptoKit (the library does that for you automatically), we'll focus on the CommonCrypto and Security libraries in this test.

## Steps

1. Run a static analysis tool such as @MASTG-TOOL-0073 on the app binary, or use a dynamic analysis tool like @MASTG-TOOL-0039, and look for uses of the cryptographic functions that generate keys.

## Observation

The output should contain the disassembled code of the functions using `CCCrypt` or other cryptographic functions.

## Evaluation

The test case fails if you can find the use of insufficient key sizes within the source code. For example, a 1024-bit key size is considered insufficient for RSA encryption and a 128-bit key size is considered insufficient for AES encryption considering quantum computing attacks.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0213

---
title: Use of Hardcoded Cryptographic Keys in Code
platform: ios
id: MASTG-TEST-0213
type: [static]
weakness: MASWE-0014
profiles: [L1, L2]
---

## Overview

In this test case, we will examine iOS applications for the presence of hardcoded cryptographic keys. Hardcoded keys can be typically found in calls to cryptographic functions or stored as constants or variables within the code. In iOS, cryptographic keys are often used in the following frameworks:

- **Security Framework**: The [`SecKeyCreateWithData`](https://developer.apple.com/documentation/security/seckeycreatewithdata(_:_:_:)) function allows developers to create a cryptographic key from raw data.
- **CommonCrypto**: The [`CCCrypt`](https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/CCCrypt.3cc.html) can be initialized with raw key data in its `key` parameter.
- **CryptoKit**: Although `CryptoKit` provides higher-level abstractions for cryptographic operations, developers might still hardcode cryptographic keys in different formats and feed it to methods like [`P256.Signing.PrivateKey.init(rawRepresentation:)`](https://developer.apple.com/documentation/cryptokit/p256/signing/privatekey/init(rawrepresentation:)) or similar.

## Steps

1. Run a static analysis tool such as @MASTG-TOOL-0073 on the app binary looking for cryptographic APIs as indicated above.

## Observation

The output should include any instances where the app uses cryptographic functions that accept raw key data. Whenever possible, the output should also try to point to the raw key data from the binary.

## Evaluation

The test fails if calls to cryptographic functions with hardcoded keys are found within binary.

You may find the keys being directly passed as arguments to cryptographic functions (byte arrays or string literals) or stored in variables or constants within the code. Typical representations of hardcoded keys include:

- **Raw Byte Arrays**: Cryptographic keys may be directly embedded in the code as arrays of `UInt8` or `Data` objects. For example, a 256-bit AES key might be represented as a `[UInt8]` array.
- **Base64-Encoded Strings**: Developers might encode cryptographic keys as Base64 strings within the code, which can be easily decoded by attackers if discovered.
- **Hex-Encoded Strings**: Keys are sometimes stored as hexadecimal strings, which are then converted to `Data` objects at runtime for cryptographic operations.

Ensure that any identified keys are indeed cryptographic keys used for security-relevant purposes. Avoid false positives by verifying the key's usage context (e.g., configuration settings or non-security-related constants might be misidentified as cryptographic keys).