There are headers (like Referer and Host) that developers tend to use in the security mechanisms they develop, but it is considered bad practice: data that is passed in those headers is derived from user inputs and shouldn’t, therefore, be trusted.
Also, there are headers that are not actually security headers by definition (like Content-Type and X-Content-Type-Options headers), but nevertheless, they play an important role in application security.
You should NEVER use the following headers in implementations of security
These headers serve as a useful add-on to the defense-in-depth strategy
1. CONTENT-TYPE HEADER
The Content-Type header is not actually a security header, and content type validation cannot be treated as a standalone security mechanism. But it is definitely an important part of the defense-in-depth strategy.
By setting Content-Type in request and response headers, the programmer can manipulate the way the server will interpret the body of the corresponding HTTP request or response. If the server doesn’t check the content header value, it leaves a possibility for an attacker to manipulate the application’s behavior by tampering with the Content-Type header content.
In the right pane, there is an example of a JQuery vulnerability that is based on the missing Content-type header.
If the datatype is not specified in
When the user agent (usually, a browser) is trying to guess the content type, it is called MIME sniffing. This feature can be abused by an attacker and the browser can be tricked into interpreting malicious data, for example, in an XSS attack.
In HTTP response, there is an X-Content-Type-Options header that has a single
nosniff directive. It indicates that the user agent should not perform MIME sniffing and should treat the body content as the content of the type specified in the Content-Type header.
X-Content-Type-Options is also not a security header, but together with Content-Type, they make a valuable input into the defense-in-depth strategy. Don’t let the user agent guess the content type, because missing content type check can lead to the execution of content that should not be executed, or to a security controls bypass.
Now let us talk about headers that should never be used in security mechanisms and the reasons behind that warning.
In the right pane, you can see an example of a security-related decision that relies on the information from the Referer header of the incoming request.
4. REFERER AND REFERER-POLICY HEADERS
The Referer header usually contains the full URL of the page that initiated the request. If the URL contains sensitive data, then ordinary legitimate requests to analytical systems or image storages disclose that data from the URL. To prevent this, one must avoid storing sensitive data in the URL and use Referrer-Policy header,
referrerpolicy HTML tag attributes.
The Referrer-Policy header instructs user agents which referrer information, sent in the Referer header, should be added to the request. In other words, Referrer-Policy is an additional control that ensures that sensitive data doesn’t leak from the Referer header.
HTML tag attributes enable similar behavior but apply it to a specific tag.
In the right pane, you can see an example of a business logic-related decision that relies on the information from the Host header of the incoming request.