CWE-922 Insecure Storage of Sensitive Information

Coverage: 4 rules in the SiteShadow rule registry target this CWE (registry v2.0.0). Regex 4 Also: Taint 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 sensitive data being stored in a way that's easier to extract than intended (plaintext on disk, secrets in config files, tokens cached without protection, sensitive exports left in shared locations).

Why it matters

Insecure storage can expose secrets or regulated data.

• Breach amplification: if an attacker gets filesystem access (or backups/logs), they immediately get plaintext.
• Compliance exposure: regulated data (PII/PHI/PCI) stored improperly increases legal/reporting burden.
• Lateral movement: stored API keys and tokens can unlock other systems.

Safer examples

1) Keep secrets out of the repo and out of disk where possible

Use environment injection or a secret manager; avoid writing tokens/keys to local files (see S01 / CWE-798).

2) Encrypt sensitive data at rest when you must store it

Use a vetted library and keys from KMS/secret manager; avoid "homebrew" crypto (see CWE-1240).

3) Lock down storage locations and lifecycle

• Store outside web root and shared temp dirs.
• Apply least-privilege filesystem permissions.
• Set retention/expiry and scrub old exports/backups.

How SiteShadow detects it (high level)

• Looks for sensitive values written to disk/config/cache and whether protections (encryption, permissions, secret managers) are present.
• Flags storage of tokens/credentials/PII in locations commonly exposed (web roots, tmp, logs).

References

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

---

← Back to Vulnerability Library