I have seen in many places that people say that headers of the following types is a vulnerability:


I can see that this gives the attacker additional information so that he can verify the known bugs on these platforms and then abuse them. But it seems to me that removing these headers can only protect you against very simple script kiddies and any serious attacks would uncover this information rather easily. E.g.

  • There has to be a way in which IIS responds differently or fails differently when intricate random garbage is sent to it compared to other servers
  • A list of known vulnerabilities in ASP.NET can be tried one by one to see if any apply + the same point as above applies to ASP.NET itself
  • Some other similar manipulations

So all in all it seems that any serious adversary would really be able to uncover that information rather simply.

And after all will removing the headers give you any benefits apart from very simple protection from script kiddies who will first target the sites that have the vulnerability like in a popular quote:

“You don’t have to run faster than the bear to get away. You just have to run faster than the guy next to you.”

P.S. You probably have much more serious issues if this information disclosure can lead to a real vulnerability.

P.P.S. There is no point to have this headers anyway since it will even benefit performance (quite negligibly though), so it's a good idea to get rid of them, but I am still curious about the whole "security" argument here

  • 2
    While it may not help in targeted attacks, reducing version info leakage will reduce opportunistic attacks. Commented Feb 5, 2016 at 16:34
  • Scenario: In the entire header it includes a lot of info (Look at panopticlick.com) and I know of one webmaster who was looking through logs and was able to warn a visitor that they had a virus on board. The mix of extensions, fonts, etc., can be pretty unique to your computer. Do you care if you can be individually singled out from other traffic?
    – SDsolar
    Commented May 25, 2017 at 6:26

5 Answers 5


OWASP defines Information Leakage as a vulnerability, so the debate is really on whether or not the specific version information should be classified as "Information Leakage".

As @Oasiscircle mentions, this information can be used as a starting point for attackers who know of specific vulnerabilities associated with specific versions. We know attackers use botnets to scan servers looking for version fingerprints, and they use this information to maintain databases of application versions and server addresses. Shodan provides a widely used database of this info. When a new exploit is introduced that targets a specific version, or if an attacker develops a 0day exploit against a version, these attackers do a simple select of their databases and strike quickly, hoping to catch some of these machines before they're patched.

Does that make knowing a specific version number a vulnerability? Not directly, but it puts you in the cross-hairs of a field of snipers, each with a hair trigger and the motivation to strike first. I'll leave it to you to determine for yourself if you consider that a vulnerability.

  • 1
    Well, if you say they do constant scanning and maintain the database, won't they do something more reliable? Like the points I mentioned to figure out the real values no matter what you return? Commented Feb 5, 2016 at 16:31
  • 2
    @IlyaChernomordik, no, reliability is not worth the effort. It's the difference between a "targeted attack" and a "target of opportunity." These attackers don't care which server they attack; as long as they get a new server the attack is worth it. So if they have a list of 1000 potential victims, they will blast the attack at all 1000 at once. Even if 900 are already patched, and 90 are mislabeled to throw off attackers, and 5 are honeypots, that means the attacker still controls 5 new servers. He doesn't care if he has some bad data, as long as it's effective enough. Commented Feb 5, 2016 at 18:41

I'm generally dubious about the benefits - as @MarkBuffalo says, lots of attackers will try every attack they know on every server they find, whether it's likely to work or not (even to the extent of trying Windows specific attacks against systems reporting that they're running RHEL).

However, it's not information you need to give out, so I am generally in favour of removing it, where this can be accomplished with minimal effort. This sometimes means reducing the output to just the name of the server (e.g. Apache, IIS) rather than completely removing the Server header, as entirely removing the header may well require introducing new software elements into the server stack.

For example, it takes one line in apache.conf to reduce an httpd Server header to "Apache", but the addition of a proxy to reduce it further. In that case, it seems safer to stick with the minimal line, rather than add an additional element, which may introduce its own flaws.

Similarly, it's easy to see when a site runs Wordpress, but I'd still recommend removing the readme file - it's just not needed, and acts a bit like the bowl of brown M&Ms rider that some rock bands infamously used: you can check it easily, and it shows whether other steps are likely to have been taken.


Let's say that today a vulnerability got announced for all Microsoft IIS 7.5 servers with a small range of ASP Net versions. I'm a malicious attacker, and I want to figure out as many servers that I can exploit as possible before sysadmins patch up the vulnerability. Wouldn't it be a much easier problem to figure out if I could ask each individual server if they are vulnerable rather than having to try the vulnerability on every single server? Plus I could log all this information on a per-server basis and know exactly who I want to attack the instant a vulnerability is found for any type of server.

Hiding your version information will not stop an attack from happening, but it will make you less of a target if attackers are looking for a specific version of hardware or software. Security by obscurity doesn't mean you're safe, but it does slow people down sometimes, and that's exactly what's needed for day zero vulnerabilities.

  • 1
    It's far more efficient to just try the vulnerability on all random servers than asking them. Some may exclude this, some may be lying. You also won't need to know who to connect to if your vulnerability introduces something to phone home. Commented Feb 5, 2016 at 15:23
  • 1
    So no more value in implementing it, than in the quote then :) @MarkBuffalo: unless this vulnerability takes 5000 requests to execute. So it's more like not showing your purse full of gold on a black market which will not stop any dedicated thieves, but might help about some robbers just wandering around Commented Feb 5, 2016 at 15:26
  • @IlyaChernomordik Good point! Commented Feb 8, 2016 at 17:28

Well say there was a new, serious vulnerability discovered in ASP.NET 4.0.30319.

Attackers can easily find vulnerable servers by using a search engine like Shodan: https://www.shodan.io/search?query=X-AspNet-Version%3A4.0.30319

Hiding the information banners protect you from non-targeted attacks when an attacker just wants some servers to compromise for adding to their botnet.

  • 1
    So the attackers (or at least these type you mentioned) won't be bothered to use some special tricks to verify the real version? Like checking for some behaviour that this exact version exhibit and instead just do a this very simple thing? Commented Feb 8, 2016 at 10:07
  • 1
    Yes, as it is not specifically targeted at your infrastructure. If it was a targeted attack, an attacker would be able to determine which exact version was running, as you say. Commented Feb 8, 2016 at 10:29
  • @SilverlightFox that's a wet dream. They will just try. Specifically, they'll try to see if you're using that vulnerable version by checking if the vulnerability they know of will work on your server. Your only hope is upgrading before the vulnerability details are known (maintainers often are informed of security holes before it's made publicly available).
    – ymajoros
    Commented Dec 14, 2021 at 14:48
  • @ymajoros - I disagree. If they're already on your server, then highly likely. However, if they have a vulnerability that works only on ASP.NET 4.0.30319 they will use Shodan to find servers definitely using that version before widening their search. The tipping point will be where everyone hides their banners, or vendors stop outputting version information entirely. Commented Feb 10, 2022 at 9:33
  • @SilverlightFox we saw it again with the log4j vulns. They were just trying. You better were not vulnerable or had the latest patch. Nobody cared about the headers, you needed the latest, fixed version (which then isn't a secret), and hackers tried anyway. What's to hide?
    – ymajoros
    Commented Feb 11, 2022 at 11:19

Serious attackers will try all vulnerabilities they (or their tools) know of, whatever server name / version you pretend you are at. This information is not trustworthy and I wouldn't trust it as a hacker.

If you're serious about security, you update your server as soon as possible. In the case of 0-day, giving the server version away wouldn't make it better or worse. If you're not up to date, that's the first problem you should solve anyway. Serious hackers would assume you're up to date (a typical worst case scenario for them), and extensively check whether that's true for bonus points and a good laugh.

Spending any time on that non-issue is a waste, we should know better.

UPDATE: this is just about security by obscurity. Maybe have a look at that answer btw: https://security.stackexchange.com/questions/16038#answer-16041

  • 2
    "Serious attackers will ..." -- citation needed. Noisy attackers will get blocked. The point of info gathering is to be more efficient. What the other answers say is that if there is a new vulnerability, then that vulnerability will be tested regardless of header info. Not that all possible exploits are fired at any arbitrary target.
    – schroeder
    Commented Dec 14, 2021 at 15:13
  • "If you're serious about security..." -- you update as soon as possible, yes. But often that's not soon enough. Weaponised exploits tend to show up faster than an org can patch. And that's a recurring issue that's part of on-going maintenance, Configuring your servers to not include the header happens once. So, the cost/benefit ratio is in favor of spending that small time to make that configuration change even if it is a small benefit.
    – schroeder
    Commented Dec 14, 2021 at 15:16
  • @schroeder citation needed yourself :-) Which study shows that hiding headers will avoid some attacks, even for some time? It's been parroted around again and again, but lacks any basis. OTOH, if you're not at the latest known safe version, you ARE going to be attacked (don't need a citation for that , do you?). If you are, there is no real point in hiding that fact. You should really be at that version anyway.
    – ymajoros
    Commented Dec 15, 2021 at 10:49
  • This is your claim. Support it. You are inverting the logic at every stage & extending your conclusions beyond reality, which is why this is wrong. Banner grab or service test, match version to vulnerability, then test. You will see this in every vulnerability scanner, which, by the way, is what "serious attackers" do. Or throw the "vulnerability du jour" at every IP. This has been the standard for a couple decades. Throwing a Minecraft vuln at an Exchange server as a matter of normal operations is simply not done.
    – schroeder
    Commented Dec 15, 2021 at 10:59
  • Why would I have the burden of proof? I never claimed hiding headers would help, those stating that should support their own claims. Serious attackers don't just throw in a vulnerability scanner and trust any header. Certainly not for a targeted attack. Of course, they won't try minecraft vulnerabilities on an exchange server, but that's because they know it's a mail server. This is actually a good illustration: hiding headers won't help you here anyway. If you want an answer with a better wording, you could try this one: security.stackexchange.com/questions/16038#answer-16041
    – ymajoros
    Commented Dec 15, 2021 at 14:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .