FAQ-000485 - Custom Settings and Configuration Security / Post-Installation Configuration and Customer Setup

If protected custom settings aren't suitable for your use case, here are some alternatives for handling credential storage: 1. **Protected Custom Metadata**: Use this if the subscriber doesn't need to view the stored credentials. It's secure and effective when implemented correctly. 2. **Encryption with Custom Objects**: Encrypt sensitive data using strong encryption algorithms with keys stored in protected custom settings or metadata. The encrypted data can then be stored in a custom object, which offers larger storage capacity. 3. **Named Credentials**: If credentials need to be configured by the subscriber, named credentials are the recommended approach. However, keep in mind that these are visible to the org admin and are best for locally generated or per-org secrets. 4. **Custom UI for Secure Storage**: Build a custom UI (using Visualforce, Aura, or LWC) to capture and securely store credentials in a managed package. This approach provides flexibility for subscriber-specific needs. Evaluate these options based on your specific requirements, such as performance, deployability, and access control.

The existing answer is well-structured and covers appropriate alternatives to protected custom settings. I made minor improvements to enhance clarity and security focus: 1. **Encryption guidance enhancement**: Added "strong encryption algorithms" to emphasize proper cryptographic practices, which aligns with avoiding bad crypto implementations. 2. **Named Credentials emphasis**: Strengthened the recommendation for named credentials by calling it "the recommended approach" rather than just "an option," which better reflects security best practices for credential management. All security rules selected are directly relevant to the FAQ content: **ApexBadCrypto**: The FAQ discusses "Encryption with Custom Objects" and storing encryption keys, making proper cryptographic implementation directly relevant to avoid weak encryption practices. **ApexSuggestUsingNamedCred**: The FAQ explicitly mentions "Named Credentials" as an alternative, and this rule promotes using named credentials for secure credential management. **AvoidHardcodedCredentialsInFieldDecls**: The FAQ discusses credential storage alternatives, and avoiding hardcoded credentials in field declarations is a core concern when implementing these storage patterns. **AvoidHardcodedCredentialsInVarDecls**: Related to the credential storage discussion, this rule prevents hardcoded credentials in variable declarations when implementing the suggested approaches. **AvoidHardcodedCredentialsInVarAssign**: The FAQ's credential storage alternatives must avoid hardcoded credentials in variable assignments during implementation. **AvoidHardcodedCredentialsInHttpHeader**: When implementing credential storage for API calls (common use case for the FAQ's scenario), avoiding hardcoded credentials in HTTP headers is essential. **ProtectSensitiveData**: The entire FAQ is about protecting sensitive credential data through proper storage mechanisms, making this rule directly applicable to the overall topic.