FAQ-000693 - Data Storage and Encryption Security / Data Classification and Handling

Current Status:VALID_RESPONSEErrorUnable to AnswerSuggests Case

Current FAQ

Question
What are considered insecure methods for storing sensitive data like API tokens?
Answer
Insecure methods for storing sensitive data like API tokens include: 1. **Public or Unprotected Fields**: Storing sensitive data in fields that are accessible to unauthorized users. 2. **Hardcoding in Code**: Embedding API tokens directly in the application code. 3. **Logging Sensitive Data**: Including API tokens in debug logs or other logs that could be accessed by unauthorized users. 4. **Unencrypted Storage**: Storing tokens without encryption or using weak encryption schemes. 5. **Client-Side Storage**: Storing secrets in client-side applications without securing them with a user-provided secret or a vendor-provided keychain. To securely store API tokens, use protected custom settings or metadata, apply strong encryption (e.g., AES-128 or higher), and store encryption keys separately in a secure location.
Enhancing FAQ...

Enhancing FAQ with AI recommendations...

AI Recommended Enhancement

Related Security Rules (click to view)
ApexBadCryptoApexSuggestUsingNamedCredAvoidHardcodedCredentialsInFieldDeclsAvoidHardcodedCredentialsInVarDeclsAvoidHardcodedCredentialsInVarAssignAvoidHardcodedCredentialsInHttpHeaderProtectSensitiveData
Question
What are considered insecure methods for storing sensitive data like API tokens?
Recommended Answer Update
Insecure methods for storing sensitive data like API tokens include: 1. **Public or Unprotected Fields**: Storing sensitive data in fields that are accessible to unauthorized users. 2. **Hardcoding in Code**: Embedding API tokens directly in the application code. 3. **Logging Sensitive Data**: Including API tokens in debug logs or other logs that could be accessed by unauthorized users. 4. **Unencrypted Storage**: Storing tokens without encryption or using weak encryption schemes. 5. **Client-Side Storage**: Storing secrets in client-side applications without securing them with a user-provided secret or a vendor-provided keychain. To securely store API tokens, use named credentials, protected custom settings, or custom metadata. Apply strong encryption (AES-256 or higher) and store encryption keys separately in a secure location.
Reasoning
The FAQ content is largely accurate but needs two minor improvements for clarity and current best practices. First, the secure storage recommendations should lead with 'named credentials' as the primary Salesforce-recommended approach before mentioning custom settings and metadata. Second, the encryption standard recommendation should be updated from 'AES-128 or higher' to 'AES-256 or higher' to reflect current security best practices, as AES-128 while still secure is not the current recommended standard for new implementations. These changes align with modern security guidance while preserving all existing information and structure. The selected security rules directly relate to the FAQ content: ApexBadCrypto relates to the 'weak encryption schemes' warning and encryption recommendations; ApexSuggestUsingNamedCred directly supports the named credentials recommendation; AvoidHardcodedCredentialsInFieldDecls, AvoidHardcodedCredentialsInVarDecls, AvoidHardcodedCredentialsInVarAssign, and AvoidHardcodedCredentialsInHttpHeader all relate to the 'hardcoding in code' insecure method; and ProtectSensitiveData relates to the overall topic of protecting API tokens and sensitive data storage.
Reasoning References