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

Protected custom metadata and protected custom settings have distinct security differences based on their use cases and implementation: 1. **Protected Custom Metadata**: - Used for storing configuration data consistent across all orgs where the managed package is installed. - Deployable and packageable, making it ideal for including sensitive data in managed packages. - Not editable by subscribers, ensuring sensitive data remains secure and unaltered. - Preferred for storing secrets or sensitive information that doesn't require frequent updates. 2. **Protected Custom Settings**: - Designed for storing subscriber-specific data or credentials that may need updates by the subscriber. - Doesn't have a built-in GUI for management, requiring developers to create custom interfaces for updates. - Considered a legacy approach but suitable for scenarios needing subscriber-specific customization. - Offers flexibility for managing data that varies between different orgs. Both options securely protect sensitive data from unauthorized access, but the choice depends on whether the data should be subscriber-specific or consistent across installations.

The existing content accurately describes the differences between protected custom metadata and protected custom settings. I made minimal refinements to improve flow and conciseness: changed 'does not have' to 'doesn't have' for a more conversational tone, and 'does not require' to 'doesn't require' for consistency. These changes align with the brand guidelines calling for conversational language and contractions. No technical content was outdated or incorrect. Regarding the selected security rules, they all relate directly to the FAQ's core topic of securely storing sensitive data: - AvoidHardcodedCredentialsInFieldDecls: This rule relates to the FAQ's discussion of storing 'secrets or sensitive information' and 'subscriber-specific data or credentials' by flagging hardcoded credentials in field declarations, which protected custom settings/metadata help avoid. - AvoidHardcodedCredentialsInVarDecls and AvoidHardcodedCredentialsInVarAssign: These rules similarly relate to the FAQ's emphasis on secure credential storage by detecting hardcoded credentials in variable declarations and assignments, which the protected storage methods discussed help prevent. - ApexSuggestUsingNamedCred: This rule suggests using Named Credentials instead of hardcoded values, which directly relates to the FAQ's discussion of proper credential storage approaches using protected custom settings and metadata. - ProtectSensitiveData: This rule directly relates to the FAQ's core message about 'securely protect sensitive data from unauthorized access' and the discussion of storing 'secrets or sensitive information.'