Security reasons to maintain a whitelist of allowed HTTP response headers

Question

As a web developer, I'm increasingly debugging issues only to find that our IT department are using our firewall to filter HTTP response headers.

They are using a whitelist of known headers, so certain newer technologies (CORS, websockets, etc) are automatically stripped until I debug the problem and request whitelisting.

The affected responses are third-party services we are consuming - so if we have an internal site that uses disqus, comments cannot be loaded because the response from disqus is having it's headers stripped. The resources we are serving are not affected, as it's only traffic coming in to the office.

Are there genuine reasons to block certain headers? Obviously there are concerns such as man-in-the-middle, redirects to phishing sites etc but these require more than just an errant header to be successful.

What are the security reasons to maintain a whitelist of allowed HTTP response headers?

Answer 1

Fingerprinting could be the main reason to strip the response headers:

https://www.owasp.org/index.php/Fingerprint_Web_Server_%28OTG-INFO-002%29

It depends on the stack that you're running, and most of the time, the information included in the response headers is configurable in each server, but it requires tampering with each serving application individually (and there might be cases when the software is privative and doesn't offer the option to set the HTTP headers).

Let's go with an easy example:

In our example datacenter, we're running a set of servers for different purposes, and we have configured them properly, so that they're returning no unnecessary metadata on the headers.

However, a new (imaginary) closed-source application for managing the print jobs is installed on one of the servers, and it offers a web interface that we want to use for whatever reason. If this application returns an additional header such as (let's say) "x-printman-version" (and it might want to do that, to ensure compatibility with clients that use its API), it will be effectively exposing its version.

And, if this print job manager has known vulnerabilities for certain versions, an attacker just has to query it to know whether this particular install is vulnerable.

This, that might not seem so important, opens a window for automated/random attacks, scanning ports of interests, and waiting for the right headers to appear ("fingerprints"), in order to launch an attack with certainty of success.

Therefore, stripping most (setting policies and rules for those that we want to keep) of the additional HTTP headers might sound sensible in an organisation.

With that being clear, stripping the headers from outgoing connections responses is overkill. It's true that they can constitute a vector, but since it's an outgoing connection, this means we "trust" the endpoint. There's no straightforward reason why an attacker with control over the trusted endpoint would use the metadata instead of the payload.

I hope this helps!