User-provided data, such as URL parameters, POST data payloads, or cookies, should always be considered untrusted and tainted. Applications
constructing HTTP response headers based on tainted data could allow attackers to change security sensitive headers like Cross-Origin Resource Sharing
headers.
Web application frameworks and servers might also allow attackers to inject new line characters in headers to craft malformed HTTP response. In
this case the application would be vulnerable to a larger range of attacks like HTTP Response Splitting/Smuggling. Most of the time this type of
attack is mitigated by default modern web application frameworks but there might be rare cases where older versions are still vulnerable.
As a best practice, applications that use user-provided data to construct the response header should always validate the data first. Validation
should be based on a whitelist.
Noncompliant code example
string value = Request.QueryString["value"];
Response.AddHeader("X-Header", value); // Noncompliant
Compliant solution
string value = Request.QueryString["value"];
// Allow only alphanumeric characters
if (value == null || !Regex.IsMatch(value, "^[a-zA-Z0-9]+$"))
{
throw new Exception("Invalid value");
}
Response.AddHeader("X-Header", value);
