CWE-644 HTTP Header Script Injection

Coverage: 3 rules in the SiteShadow rule registry target this CWE (registry v2.0.0). Regex 3 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 response headers (or header-derived values) being influenced by untrusted input in a way that can change how a browser interprets the response. This often overlaps with CRLF/response splitting, but can also be "content-type / filename / redirect" manipulation.

Why it matters

Header injection can lead to XSS or response splitting.

• XSS/content sniffing issues when attackers influence Content-Type, Content-Disposition, or similar headers.
• Cache poisoning and redirect abuse when headers like Location or caching directives are influenced.
• Response splitting when CR/LF characters make the browser/proxy treat injected text as a new header/body (see CWE-113 / CWE-93).

Safer examples

1) Never place untrusted input into header names/values

Treat header values as strict data; reject control characters (\r, \n) outright.

if "\r" in value or "\n" in value:
    raise ValueError("Invalid header value")

2) Use safe header APIs and fixed header sets

Only set a fixed allowlisted set of headers; avoid "set header from request param".

3) Use defensive browser headers

Set X-Content-Type-Options: nosniff, and serve user-controlled downloads with safe Content-Disposition.

How SiteShadow detects it (high level)

• Detects header-setting code where values are derived from request/user-controlled sources.
• Flags especially risky headers (Content-Type, Location, Set-Cookie, caching) and control-character edge cases.

References

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

---

← Back to Vulnerability Library