FAQ-000504 - Custom Settings and Configuration Security / Protected Custom Settings vs Other Storage Methods

Restricted/encrypted fields and Protected Custom Settings differ significantly in their suitability for storing API keys: 1. **Restricted/Encrypted Fields**: - Use encryption (e.g., AES with 128-bit keys) to secure data. - Accessible to users with the "View Encrypted Data" permission, which can pose a security risk for API keys. - Not recommended for storing API keys or other authentication data due to potential exposure risks. 2. **Protected Custom Settings**: - Specifically designed for securely storing sensitive data like API keys and authentication credentials. - Not visible to users through the UI, providing an additional layer of security. - More secure and appropriate for storing API keys compared to encrypted fields. **Best Practice**: For the most secure approach, consider using Named Credentials instead of storing API keys directly. Named Credentials provide the highest level of security for managing external service authentication. In summary, Protected Custom Settings are the preferred choice over encrypted fields for securely storing API keys, as they're designed to handle such sensitive data securely.

The FAQ content is accurate and well-structured, but it misses an important security best practice that's directly relevant to the question. The ApexSuggestUsingNamedCred rule specifically addresses API key storage and suggests using Named Credentials as the most secure approach. The FAQ currently positions Protected Custom Settings as the best option without mentioning Named Credentials, which is actually the recommended best practice for API key management. I added a brief mention of Named Credentials as the optimal approach while preserving all existing content and maintaining the FAQ's structure. This provides users with complete information about all available options, from least to most secure: encrypted fields < Protected Custom Settings < Named Credentials. The ApexSuggestUsingNamedCred rule relates to this FAQ because it specifically deals with storing and managing API keys and authentication credentials, which is exactly what the FAQ question asks about.