Server Version Disclosure

Server version disclosure is when your web server advertises its exact software name and version in HTTP response headers — values like Server: nginx/1.18.0 or X-Powered-By: PHP/7.4.3. It's a low-severity information leak: check for it with a one-line curl -I, and fix it by suppressing the version banner in your server config.

What is Server Version Disclosure?

Every HTTP response carries headers that describe the server which produced it. By default, many stacks fill these in with more detail than they need to. The Server header names the web server and its version (nginx/1.18.0, Apache/2.4.41), and the application layers pile on their own: X-Powered-By: PHP/7.4.3, X-AspNet-Version from ASP.NET, X-Generator from CMS platforms, and similar. None of this is required for the site to function — it's diagnostic metadata that ships enabled and is rarely turned off.

Because it exposes precise implementation details to anyone who asks, it maps to OWASP A05: Security Misconfiguration — the same hardening family as a directory listing vulnerability and an enabled HTTP TRACE method. It's a routine audit and compliance finding, not a live exploit.

Why it's a risk / how it's exploited

Be honest about severity: version disclosure does not let anyone in by itself. It's reconnaissance. Its value to an attacker is that it removes guesswork.

Here's the realistic scenario. An attacker profiling your site reads Server: nginx/1.18.0 and X-Powered-By: PHP/7.4.3 straight from the response headers. Instead of blindly probing, they look up published CVEs for exactly those versions, confirm which known bugs apply, and load the matching exploit modules first. If either component is behind on patches, you've handed them a shortlist of what to try. If everything is current, the disclosure only told them your stack is well-maintained — still useful to them, but far less dangerous to you.

That's the whole risk: it's a force multiplier for recon, not a vulnerability that stands on its own. Rated low — worth closing as hardening and to pass audits, not an emergency.

How to detect it

Read the response headers with curl and grep for the usual banners:

curl -sI https://example.com | grep -iE 'server|x-powered-by|x-aspnet-version'

A disclosing server returns something like Server: nginx/1.18.0 and X-Powered-By: PHP/7.4.3 — the version number is the finding. A hardened one returns only a generic token (Server: nginx) or drops the header entirely, and shows no X-Powered-By or X-AspNet-Version line at all. You can see the same headers in your browser's DevTools under Network → (request) → Headers.

For a full picture, an automated vulnerability scan flags version banners across every host, and our security headers checker shows your response headers at a glance.

How to fix it

Suppress the version details at each layer that sets them.

nginx — hide the version number in nginx.conf (inside the http block):

server_tokens off;

This turns Server: nginx/1.18.0 into Server: nginx. Removing the nginx name entirely requires the third-party headers-more module:

more_clear_headers Server;

Apache — in httpd.conf or apache2.conf:

ServerTokens Prod
ServerSignature Off

ServerTokens Prod reduces the header to Server: Apache, and ServerSignature Off removes the version line from server-generated error pages.

Remove X-Powered-By (PHP). Turn off PHP's banner in php.ini:

expose_php = Off

Or strip it from the application with header_remove('X-Powered-By');. If you can't touch the app, remove it at the proxy — nginx:

proxy_hide_header X-Powered-By;

Apache with mod_headers:

Header unset X-Powered-By

Critical caveat: hiding the banner is defense-in-depth only — it is not a substitute for patching. Obscuring nginx/1.18.0 slows an attacker's recon, but if that version is genuinely vulnerable, the flaw is still there and still exploitable. Keep the software updated first; hide the version second.

FAQ

Does hiding the server version actually make me more secure? Marginally. It raises the effort of reconnaissance and clears a common audit finding, but it changes nothing about whether your software is vulnerable. A patched server that discloses its version is safer than an unpatched one that hides it. Treat it as tidy-up, not protection.

Can't an attacker fingerprint my version anyway? Often yes — behavioral quirks, error-page wording, and default file paths can reveal a stack even without the banner. Removing the header just makes that work harder and slower, which is the entire point of a defense-in-depth control.

---

Not sure what your headers are giving away? Run a free website vulnerability scan to catch version banners and other security misconfigurations across your site.