What is the HTTP "Server" response-header field used for?

  • It was not until recently that I began to question the use for the Server field in the HTTP Response-Header.

    I did some research:

    RFC 2616 states:

    14.38 Server

    The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.

       Server         = "Server" ":" 1*( product | comment )


       Server: CERN/3.0 libwww/2.17

    If the response is being forwarded through a proxy, the proxy application MUST NOT modify the Server response-header. Instead, it SHOULD include a Via field (as described in section 14.45).

      Note: Revealing the specific software version of the server might
      allow the server machine to become more vulnerable to attacks
      against software that is known to contain security holes. Server
      implementors are encouraged to make this field a configurable

    This, however, makes no mention of the purpose of this field. This seems like information disclosure to me. These server strings give away a lot of information that is great for anyone trying to fingerprint the server. Automated scanning tools would quickly identify unpatched or vulnerable servers. Having my web server present version information for itself and modules like OpenSSL seems like a bad idea.

    • Is this field needed... for anything? If so, what?
    • Is it already best practice / common place to disable or change this field on servers?

    I would think that, from a security perspective, we would want to give the enemy (ie: Everyone) as little information as possible while still allowing business to continue. Here is an interesting write-up on information warfare.

  • rook

    rook Correct answer

    9 years ago

    Server information should be removed from HTTP responses, and its an insecure default to leak this data. This isn't a major security risk, or even a medium security risk - but I don't feel comfortable just announcing such details to my adversaries. Having an exact version number leaks when, and how often you patch your production systems - even if the version is current. An adversary knowing the patch cycle, means that they know when you are the weakest.

    The HTTP Host header probably most useful for the Netcraft Web Server Survey. But in terms of HTTP it shouldn't matter. That is why we have standards, so that clients and servers written by different vendors can work together.

    This was my thinking as well.

    Insecure might be a bit much. Its a form of information disclosure, but that alone doesn't make it insecure because there is no definition of secure.

    @SteveS information disclosure vulnerabilities are a low finding and are on nearly every penetration test report I write because it is default. This is also a CWE violation.

    stackexchange exposes it in the header

    @Ced stack exchange has a lot of problems, did you load this page over HTTP? With a session? Hmm...

    Most of the things that you'd be worried about here - such as leaking how often you patch production systems - are easy to figure out anyway. If telling someone what version / server your software is using is causing any sort of security issue, you have bigger problems than this HTTP header.

License under CC-BY-SA with attribution

Content dated before 7/24/2021 11:53 AM

Tags used