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

Store customer-provided credentials configured after installation using **protected custom settings** or **protected custom metadata**: - **Protected custom settings** are ideal for legacy implementations - **Protected custom metadata** works well for modern use cases Both options ensure sensitive data isn't publicly accessible. You can also use **Named Credentials** for locally generated or per-organization secrets, but keep in mind that administrators can view these. Implement proper encryption and access controls, and avoid storing sensitive data in public custom settings, custom objects, or unencrypted fields.

The original FAQ content is technically accurate and covers the key security concepts well. I made minor improvements to enhance clarity and flow: 1. **Clarity improvements:** Changed "are not publicly accessible" to "isn't publicly accessible" for more conversational tone, and "Make sure to implement" to "Implement" for directness following the brand guidelines. 2. **Flow enhancement:** Removed "Additionally" to create smoother transitions between concepts. No outdated content was detected - the recommendations for protected custom settings, protected custom metadata, and Named Credentials remain current best practices. **Security Rules Selected:** - **AvoidHardcodedCredentialsInFieldDecls, AvoidHardcodedCredentialsInVarDecls, AvoidHardcodedCredentialsInVarAssign, AvoidHardcodedCredentialsInHttpHeader:** These rules directly relate to the FAQ's core message about avoiding hardcoded credentials. The FAQ specifically warns against "storing sensitive data in public custom settings, custom objects, or unencrypted fields" which aligns with these rules that detect hardcoded credentials in various code contexts. - **ApexSuggestUsingNamedCred:** This rule suggests using Named Credentials, which the FAQ explicitly mentions as an option for "locally generated or per-organization secrets." - **ProtectSensitiveData:** This rule broadly covers protecting sensitive information, which is the entire focus of this FAQ about securely storing "customer-provided credentials."