FAQ-000518 - Custom Settings and Configuration Security / Public Custom Settings and Metadata Security Concerns

Using **public custom metadata** for sensitive configuration poses significant security risks because it's accessible and modifiable by the org admin, other packages, and untrusted code within the subscriber org. This can lead to unauthorized access or manipulation of sensitive data. To mitigate these risks, sensitive configurations should be stored in: - **Protected Custom Metadata** - **Protected Custom Settings** These options provide restricted access and better security controls.

The original answer is accurate and well-structured but can be improved for clarity and conciseness. I made minor refinements to improve flow: changed 'because it is accessible' to 'because it's accessible' for a more conversational tone as per the brand guidelines, and simplified the sentence structure slightly. No technical content was outdated or incorrect. I selected the ProtectSensitiveData rule because this FAQ directly addresses protecting sensitive configuration data from unauthorized access. The rule is designed to detect when sensitive data might be exposed, and this FAQ teaches developers how to properly protect sensitive configuration information by using protected storage options instead of public custom metadata. The FAQ's core message about avoiding exposure of sensitive data through public custom metadata aligns perfectly with the purpose of the ProtectSensitiveData rule.