Skip to content
Open
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 10 additions & 2 deletions best-practices/MASTG-BEST-0026.md
Original file line number Diff line number Diff line change
Expand Up @@ -3,6 +3,14 @@ title: Preventing Keyboard Caching for Sensitive Text Inputs
alias: preventing-keyboard-caching-for-sensitive-text-inputs
id: MASTG-BEST-0026
platform: ios
status: placeholder
note: This topic explains best practices to prevent sensitive text inputs from being cached by the iOS keyboard.
---

Sensitive text inputs should never participate in keyboard learning or prediction. On iOS, this means explicitly disabling features that allow the system keyboard to cache or reuse previously entered values. By default, standard text fields are eligible for caching unless told otherwise, which makes explicit configuration essential for any field that handles secrets or identifiers.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Sensitive text inputs should never participate in keyboard learning or prediction. On iOS, this means explicitly disabling features that allow the system keyboard to cache or reuse previously entered values. By default, standard text fields are eligible for caching unless told otherwise, which makes explicit configuration essential for any field that handles secrets or identifiers.
Sensitive text inputs should never participate in keyboard learning or prediction. What is defined as sensitve text, should be carefully evaluated for all text input based on data protection laws, industry regulations, company policies or individual assessment.
On iOS, this means explicitly disabling features that allow the system keyboard to cache or reuse previously entered values. By default, standard text fields are eligible for caching unless told otherwise, which makes explicit configuration essential for any field that handles secrets or identifiers.

Should we add a sentence about how to classify data first (data protection law, industry standard like PCI-DSS, etc.)?

Because this best practice should be applied to all text input and not just obvious ones like password forms. For example, an app for lawyers, or critical infrastructure can have many sensitive text input forms.


- For inputs such as usernames, email addresses, recovery codes, and similar data, set `autocorrectionType` to `no` and `spellCheckingType` to `no`. Autocorrection and spell checking rely on analyzing typed content and may retain or resurface that content through suggestions. Disabling both traits ensures the keyboard does not treat these values as language data worth remembering or reusing.

- For password like inputs, always enable `isSecureTextEntry`. Secure text entry masks characters on screen and implicitly disables autocorrection and spell checking. This provides the strongest baseline protection for secrets and avoids accidental exposure through keyboard suggestions, predictive text, or third party keyboards.
Comment thread
cpholguera marked this conversation as resolved.
Outdated
Comment thread
cpholguera marked this conversation as resolved.
Outdated

These traits must be applied consistently across the entire application. Configure them in code or Interface Builder for every security sensitive field, including login, registration, account recovery, payment, and profile related screens.
Comment thread
cpholguera marked this conversation as resolved.
Outdated
Comment thread
cpholguera marked this conversation as resolved.
Outdated

Any exceptions should be rare and well justified. If spell checking or autocorrection cannot be disabled due to strong usability requirements, the risk should be explicitly assessed and documented.
11 changes: 7 additions & 4 deletions knowledge/ios/MASVS-STORAGE/MASTG-KNOW-0100.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,9 +4,12 @@ platform: ios
title: Keyboard Cache
---

Several options, such as autocorrect and spell check, are available to users to simplify keyboard input and are cached by default in `.dat` files in `/private/var/mobile/Library/Keyboard/` and its subdirectories.
Several features such as autocorrection, spell checking, and predictive suggestions help users enter text more quickly. On iOS, these features are backed by on device keyboard dictionaries that are persisted in `.dat` files under `/private/var/mobile/Library/Keyboard/` and its subdirectories. Forensic analyses and security research show that user typed terms, including previously unknown words, can appear in files such as `dynamic-text.dat` in this directory and may be recoverable during device analysis.
Comment thread
cpholguera marked this conversation as resolved.
Outdated
Comment thread
cpholguera marked this conversation as resolved.
Outdated

The [UITextInputTraits protocol](https://developer.apple.com/reference/uikit/uitextinputtraits "UITextInputTraits protocol") is used for keyboard caching. The `UITextField`, `UITextView`, and `UISearchBar` classes automatically support this protocol and it offers the following properties:
The system uses the [`UITextInputTraits`](https://developer.apple.com/documentation/uikit/uitextinputtraits) protocol to control how keyboard assistance and learning behave for a given text control. Standard UIKit controls like [`UITextField`](https://developer.apple.com/documentation/uikit/uitextfield), [`UITextView`](https://developer.apple.com/documentation/uikit/uitextview), and [`UISearchBar`](https://developer.apple.com/documentation/uikit/uisearchbar) conform to this protocol and expose these traits directly.

- `var autocorrectionType: UITextAutocorrectionType` determines whether autocorrection is enabled during typing. When autocorrection is enabled, the text object tracks unknown words and suggests suitable replacements, replacing the typed text automatically unless the user overrides the replacement. The default value of this property is `UITextAutocorrectionTypeDefault`, which for most input methods enables autocorrection.
- `var secureTextEntry: BOOL` determines whether text copying and text caching are disabled and hides the text being entered for `UITextField`. The default value of this property is `NO`.
Key traits that influence what the keyboard learns include
Comment thread
cpholguera marked this conversation as resolved.
Outdated

- [`autocorrectionType`](https://developer.apple.com/documentation/uikit/uitextinputtraits/autocorrectiontype) (default: `UITextAutocorrectionType.default`, enabled): This property controls whether the system attempts to correct what the user types. With autocorrection enabled, the system analyzes entered text, tracks unfamiliar words, and proposes replacements, sometimes substituting them automatically unless the user rejects the suggestion. The default value delegates the decision to the current keyboard and input method, which typically results in autocorrection being enabled.
- [`spellCheckingType`](https://developer.apple.com/documentation/uikit/uitextinputtraits/spellcheckingtype) (default: `UITextSpellCheckingType.default`, enabled): This property controls spell checking behavior. When enabled, the system underlines suspected misspellings and offers alternatives. Spell checking uses the same underlying language services as autocorrection and contributes to recently observed words that influence suggestions and keyboard learning.
- [`isSecureTextEntry`](https://developer.apple.com/documentation/uikit/uitextinputtraits/issecuretextentry) (default: `false`, disabled): This property hides the displayed characters and is **intended for password-like inputs**. Apple documents that enabling secure text entry disables copy operations and suppresses keyboard features that analyze or transform input, including autocorrection and spell checking. While this behavior prevents secure fields from participating in normal keyboard learning and suggestion mechanisms, Apple does not provide a formal guarantee about all forms of internal storage or handling, and therefore secure text entry should be treated as a strong mitigation rather than an absolute guarantee.
Loading