CWE-644 HTTP Header Script Injection
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
Locationor 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
---