FAQ-000557 - Custom Settings and Configuration Security / Specific Use Cases and Implementation Patterns

Acceptable alternatives to protected custom settings for storing sensitive data in managed packages include: 1. **Protected Custom Metadata API Fields**: These are preferred for securely storing secrets. 2. **Named Credentials**: Suitable for locally generated or per-org secrets, though administrators can view these. 3. **Encrypted Custom Object Fields**: Sensitive data can be encrypted, with the encryption key stored separately in a protected custom setting or hidden custom metadata API field. Use proper permissions and Apex Crypto calls for encryption. Choose the option that best fits your use case and access requirements.

The FAQ content is accurate and well-structured. I made one minor improvement to enhance clarity in point 3 by changing 'Proper permissions and Apex Crypto calls should be used for encryption' to 'Use proper permissions and Apex Crypto calls for encryption' - this makes the guidance more direct and actionable while maintaining the same meaning. Regarding the related security rules: - ApexBadCrypto: Directly relates to point 3 which mentions 'Apex Crypto calls' for encryption - this rule helps detect improper cryptographic implementations - ApexSuggestUsingNamedCred: Directly relates to point 2 which discusses Named Credentials as an alternative for storing secrets - AvoidHardcodedCredentialsInFieldDecls, AvoidHardcodedCredentialsInVarDecls, AvoidHardcodedCredentialsInVarAssign: All three relate to the overall FAQ topic of secure storage alternatives to prevent hardcoded credentials, which is the core problem this FAQ addresses - ProtectSensitiveData: Relates to the entire FAQ content as it covers protecting sensitive data in managed packages, which is exactly what this rule is designed to enforce