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

To securely store sensitive data in managed packages, follow these security requirements: 1. **Protected Custom Settings or Metadata**: Use protected custom settings or custom metadata types to store sensitive data like API keys, passwords, or cryptographic keys securely. 2. **Encryption**: Encrypt sensitive data stored in custom objects and keep the encryption key in a protected custom setting or protected custom metadata type field. Configure permissions properly for fields containing encrypted secrets. 3. **Named Credentials**: Use named credentials for externally managed secrets like third-party API keys. Note that administrators can view these, so they may not be suitable for all use cases. 4. **Avoid Public Visibility**: Don't store sensitive data in public custom settings, objects, or metadata to prevent access by untrusted code or other packages. 5. **Secure Coding Practices**: Use Apex Crypto calls for encryption, avoid logging sensitive data in debug logs, and use the `transient` keyword to prevent storage in viewstate when updating protected custom settings. 6. **Web Service and Callout Code**: Protect fields used as authenticators in web service or callout code using the above mechanisms. 7. **Compliance with Standards**: Adhere to enterprise security standards, such as using AES-128 or higher encryption for server-side secrets and secure storage mechanisms for client-side applications. These practices help mitigate risks and comply with Salesforce's security review requirements.

The answer is largely accurate but contains minor wording inconsistencies that could be clarified. I made the following improvements: (1) Changed 'metadata API fields' to 'custom metadata types' for consistency with Salesforce terminology, (2) Clarified 'hidden custom metadata API field' to 'protected custom metadata type field' for accuracy, (3) Refined the named credentials description from 'locally generated or per-org secrets' to 'externally managed secrets like third-party API keys' to better reflect their typical use case. These changes improve technical precision without altering the content structure or adding new information. Regarding the selected security rules: ApexBadCrypto relates to the FAQ's discussion of using proper Apex Crypto calls for encryption. ApexSuggestUsingNamedCred directly corresponds to the named credentials recommendation for managing secrets. The hardcoded credentials rules (AvoidHardcodedCredentialsInFieldDecls, AvoidHardcodedCredentialsInVarDecls, AvoidHardcodedCredentialsInVarAssign, AvoidHardcodedCredentialsInHttpHeader) all relate to the FAQ's guidance on avoiding public storage of sensitive data and using protected storage mechanisms instead. ProtectSensitiveData encompasses the overall theme of the FAQ about securing sensitive data in managed packages through proper storage mechanisms and encryption practices.