Do I need to remove the Server header from my HTTP responses?

You might have heard the recommendation that your web server should not return the Server header to reveal exactly what software is being used. It even says so in the RFC. Given how hard it was to remove the Server header when using .Net HttpListener you might wonder what is really the right thing to do here.

As usual the best answer is it depends. The old security argument for not having the Server header there is nonsense if you ask me. Any serious attacker is not going to identify your vulnerabilities based on server software versions. A serious attacker either knows or will try all possible vulnerable versions you might be running.

Another argument might be to remove any non-significant headers to reduce the number of bytes transmitted for better performance. Sure this is a valid argument if you client is connecting to you over dial-up internet using a satellite phone...

However since it is more and more common that services are hosted in public clouds where you pay for bytes transmitted the argument for removing non-significant headers as the Server header might save you some money. But unless you run a huge service like google (they send the Server header) or facebook (they do not send the Server header) this probably doesn't matter for you.

So if you are using a web server where it is hard to remove the Service header (like the .Net HttpListener), then just let it be. There are probably more important things for you to focus on...


  1. Incomplete from my pov. Just arguments to: leave it because it's to hard. While it should be: work a little harder and get things right. lboshuizen

  2. I think the actual argument should be "why the hell is that header there at the first place?". I know why but I just don't care about vendor's usage reports.

  3. I also find articles advocating silly security by obscurity changes detract from the imperativeness of proper security management. Maybe one person on the planet got hacked by exposing that information about the server, but hundreds of thousands if not millions get hacked from leaking credentials, failure to have account lockout policies, and databases that are in plain-text or effectively plain-text from improper use of hashing.