FAQ-000464 - Custom Settings and Configuration Security / Custom Metadata Security and Visibility Management

Current Status:VALID_RESPONSEErrorUnable to AnswerSuggests Case

Current FAQ

Question
Why is a public Custom Metadata Type considered a potential 'Insecure Storage' vulnerability?
Answer
A public Custom Metadata Type is considered a potential "Insecure Storage" vulnerability because it allows sensitive data, like API keys or credentials, to be accessible and modifiable not only by the org administrator but also by other packages and untrusted code within the subscriber org. This exposure increases the risk of unauthorized access and misuse of sensitive information. To mitigate this, it's recommended to use protected custom settings or protected custom metadata to securely store such data. API endpoint URLs can be stored in Protected Custom Metadata within a package to ensure that the data is secure and not accessible to unauthorized users or external packages.
Enhancing FAQ...

Enhancing FAQ with AI recommendations...

AI Recommended Enhancement

Related Security Rules (click to view)
ProtectSensitiveDataAvoidHardcodedCredentialsInFieldDeclsAvoidHardcodedCredentialsInVarDeclsAvoidHardcodedCredentialsInVarAssign
Question
Why is a public Custom Metadata Type considered a potential 'Insecure Storage' vulnerability?
Recommended Answer Update
A public Custom Metadata Type is considered a potential "Insecure Storage" vulnerability because it allows sensitive data, like API keys or credentials, to be accessible and modifiable not only by the org administrator but also by other packages and untrusted code within the subscriber org. This exposure increases the risk of unauthorized access and misuse of sensitive information. To mitigate this, it's recommended to use protected custom settings or protected custom metadata to securely store such data. API endpoint URLs can be stored in Protected Custom Metadata within a package to ensure that the data is secure and not accessible to unauthorized users or external packages.
Reasoning
The FAQ content is accurate and well-structured, explaining the security concerns with public Custom Metadata Types and providing appropriate mitigation strategies. No significant changes were needed as the content correctly identifies the vulnerability and offers proper solutions. The selected security rules are highly relevant to this FAQ's content: ProtectSensitiveData directly addresses the core concept of securing sensitive information like API keys and credentials that the FAQ discusses. The three AvoidHardcodedCredentials rules (AvoidHardcodedCredentialsInFieldDecls, AvoidHardcodedCredentialsInVarDecls, AvoidHardcodedCredentialsInVarAssign) are relevant because they detect hardcoded credentials in code, which relates to the FAQ's warning about storing sensitive data like API keys and credentials in public Custom Metadata Types where they could be exposed. The FAQ specifically mentions 'API keys or credentials' and 'sensitive data' which directly aligns with what these rules are designed to protect against.
Reasoning References