CWE-200 Sensitive Data Exposure

Coverage: 18 rules in the SiteShadow rule registry target this CWE (registry v2.0.0). Regex 17Other-pattern 1 Also: AI-context engineTaint and heuristic analyzers may also detect related flows (see coverage for the authoritative list) Registry tagging shows intent, for sample-level behaviour and benchmarked gaps see known gaps.

What this means

SiteShadow flagged a place where sensitive information is exposed to users or systems that shouldn't have it (overly broad API responses, debug endpoints, insecure storage/permissions, or leaked secrets).

Why it matters

Sensitive data exposure can lead to account compromise or privacy breaches.

• Privacy incidents (PII/PHI leak) and compliance exposure.
• Credential theft: exposed tokens/keys can lead to further compromise.
• Recon for attackers: internal data makes other exploitation easier.

Safer examples

1) Return the minimum data needed (response allowlists)

res.json({ id: user.id, name: user.name }); // not the full user object

2) Separate public vs private fields

Keep "internal-only" data out of DTOs returned to clients.

3) Protect non-obvious leak paths

• Don't expose stack traces or internal config (see E01 / A05)
• Avoid secrets in URLs/logs (see S01 / L01 / CWE-532)

How SiteShadow detects it (high level)

• Looks for risky sinks (HTTP responses, logs, errors) that include sensitive fields.
• Uses heuristics around common sensitive keys (tokens, passwords, SSNs, API keys) and data structures.

References

• CWE-200: https://cwe.mitre.org/data/definitions/200.html

---

← Back to Vulnerability Library