FAQ-000718 - Data Storage and Encryption Security / Secure Storage Best Practices

The approved platform features for storing secrets and credentials in Salesforce are: 1. **Protected Custom Metadata**: The preferred method for securely storing secrets, ensuring they're accessible only to authorized users. 2. **Named Credentials**: Suitable for locally generated or per-org secrets. While administrators can view these credentials, they provide built-in secure storage and are recommended by Salesforce for avoiding hardcoded credentials in code. 3. **Protected Custom Settings**: A legacy option for storing secrets, requiring custom code to manage these settings as there's no built-in UI. 4. **Encrypted Custom Objects**: Secrets can be stored in custom objects with encryption applied, and the encryption key must be stored separately in a protected custom setting or hidden custom metadata API field. Proper permissions, encryption, and secure handling are essential when using these features to prevent unauthorized access or exposure.

The main issue with the original answer was the ordering and characterization of Named Credentials. The FAQ positioned Named Credentials third with a cautionary note about administrator visibility, but several security rules (ApexSuggestUsingNamedCred) specifically recommend using Named Credentials to avoid hardcoded credentials. This creates confusion about whether Named Credentials should be avoided or embraced. I reordered the list to place Named Credentials second (after Protected Custom Metadata) and reframed the administrator visibility as context rather than a limitation, emphasizing that they're still recommended by Salesforce. This aligns with the security rules that flag hardcoded credentials as violations while suggesting Named Credentials as the solution. Regarding the selected security rules: - ApexSuggestUsingNamedCred: Directly relates to the FAQ's discussion of Named Credentials as an approved storage method - AvoidHardcodedCredentialsInFieldDecls, AvoidHardcodedCredentialsInVarDecls, AvoidHardcodedCredentialsInVarAssign: All relate to why proper credential storage (as described in the FAQ) is necessary to avoid hardcoding secrets in various code contexts - AvoidHardcodedCredentialsInHttpHeader: Relates to the FAQ's guidance on secure credential storage for HTTP authentication scenarios - AvoidHardcodedCredentialsInSetPassword: Connects to the FAQ's discussion of secure password/credential management approaches - AvoidHardCodedCredentialsInAura and AvoidHardcodedSecretsInVFAttrs: Apply to the frontend contexts where the FAQ's recommended storage methods would prevent hardcoded secrets - ApexBadCrypto: Relates to the FAQ's mention of encryption requirements for custom objects storing secrets