FAQ-000460 - Custom Settings and Configuration Security / Alternative Storage Methods and Recommendations

If protected custom settings or metadata aren't compatible with your integration tools or architecture, here are the recommended secure alternatives for storing secrets and API keys: 1. **Named Credentials**: Securely store authentication data like client IDs and secrets for callouts. However, note that administrators can view these credentials, so they're best for locally generated or per-org secrets. 2. **Protected Custom Metadata API Fields**: This is a preferred method for securely storing secrets in managed packages. It ensures sensitive data isn't accessible or modifiable by unauthorized users or packages. However, ensure the metadata isn't accessible through the License Management Application (LMA) if that's a concern. 3. **Encrypted Custom Objects**: Store encrypted secrets in custom objects, and keep the encryption key separately in a protected custom setting or a hidden custom metadata API field. Use Apex Crypto calls to handle encryption and decryption securely. Make sure to configure permissions properly for fields containing encrypted secrets to maintain security. Each method has specific use cases, so choose based on your application's security, performance, and accessibility needs.

The main improvements focus on making the content more conversational and concise while preserving all original technical information. Changed 'However, note that administrators can view these credentials' to use the contraction 'they're' and similar conversational improvements throughout. The technical content remains accurate and complete. Related security rules selected: - ApexSuggestUsingNamedCred: Directly relates to the FAQ's first recommendation about using Named Credentials for storing authentication data and API keys - AvoidHardcodedCredentialsInFieldDecls: Relates to the FAQ's discussion of securely storing secrets instead of hardcoding them in field declarations - AvoidHardcodedCredentialsInVarDecls: Connects to the FAQ's guidance on secure storage alternatives instead of hardcoding credentials in variable declarations - AvoidHardcodedCredentialsInVarAssign: Relevant to the FAQ's recommendations for secure credential storage instead of hardcoding in variable assignments - AvoidHardcodedCredentialsInHttpHeader: Applies to the FAQ's discussion of secure alternatives for storing API keys that would be used in HTTP headers - ApexBadCrypto: Directly relevant to the FAQ's third recommendation about using 'Apex Crypto calls to handle encryption and decryption securely'