[Feedback] How is 'ProtectSensitiveData' flagged?

[varsh-acn]

Feedback

Hi, I would like to understand more on how the 'ProtectSensitiveData' rule is flagged because there seem to be instances where fields that are not an auth token or have no key words that suggest it's a token are flagged for this rule.

Is the rule flagged due to certain keywords being detected in the field name? Or is something detected in the xml file?

Thanks

Context

No response

Suggestions

No response

Additional Information

No response

[aruntyagiTutu]

Thanks for the question. @varsh-acn

The ProtectSensitiveData rule is flagged based on heuristics. It mainly looks at the field name (from the .field-meta.xml filename) and, for token-like fields, also checks the parent object’s type and visibility in the .object-meta.xml.

Because of this, the rule can trigger on keyword or substring matches such as ACCESS, KEY, or TOKEN, even if the field isn’t actually storing a secret.

A few general recommendations:

• Store secrets in Protected Custom Metadata or Protected Custom Settings, and avoid public visibility.
• Use EncryptedText for privacy-related fields like SSN or passport numbers.
• If a field is not sensitive, consider renaming it to avoid ambiguous keywords.

To help us triage this better, could you share:

• The exact field(s) that were flagged (the .field-meta.xml file)
• The parent object’s .object-meta.xml
• The field type and parent object type (__c, __mdt, or Custom Setting)
• Your Code Analyzer version and the command you ran
• Whether the flagged fields actually store sensitive data or just have benign names (for example, PublicKeyLabel__c)

If this turns out to be a false positive, typical options are renaming the field, moving it to protected metadata/settings (if it’s a real secret), or disabling/overriding the rule for that field if your policy allows.