The fix, in one snippet
server_tokens off; # nginx
ServerTokens Prod # Apache
ServerSignature Off # ApacheIllustrative values. Change the paths, hostnames and options to match your own site before using it.
The sections below explain what is tested, why it matters and the alternatives.
What we test
Scan.now reads the Server response header on / and on the 404 page it requests as part of the exposure checks (Apache's default error page can also append a ServerSignature footer with the same details). The check fails when the value contains a version number, detected as a dotted numeric sequence, for example nginx/1.24.0, Apache/2.4.58 (Ubuntu) OpenSSL/3.0.2, Microsoft-IIS/10.0 or LiteSpeed with a version. A bare product name (nginx, Apache, cloudflare) passes: hiding the product entirely is optional and rarely worth a custom module. Application-layer disclosures such as X-Powered-By: PHP/8.1.2 are a separate check, x-powered-by-disclosure, and CMS versions are covered by generator-disclosure.
Why it matters
A version string lets an attacker go straight from reconnaissance to a shortlist of CVEs. Template-driven scanners such as Nuclei and mass-exploitation bots select what to try based on exactly this kind of banner, so a precise version makes you a more efficient target. Removing it does not fix any underlying vulnerability, and a determined tester can still fingerprint a server from its behaviour, so this is rated low. It is also worth knowing that distribution version strings can mislead: Debian and Ubuntu backport security fixes without changing the upstream version number, so Apache/2.4.58 (Ubuntu) may be fully patched while looking vulnerable. That cuts both ways: it invites unnecessary attention from automated tools. RFC 9110 itself advises that servers SHOULD NOT generate detailed product versions. The security headers guide covers the other disclosure headers.
How to fix it
nginx reduces the header to the bare product name with one directive; removing it entirely requires the headers-more module:
server_tokens off;
# with ngx_headers_more installed:
# more_clear_headers Server;Apache (set globally, for example in conf-available/security.conf):
ServerTokens Prod
ServerSignature OffIIS 10 and later, in web.config:
<system.webServer>
<security>
<requestFiltering removeServerHeader="true" />
</security>
</system.webServer>Node.js does not send a Server header on its own; if you see one on an Express app, it comes from the reverse proxy in front of it, so fix it there. Cloudflare replaces the origin's Server header with cloudflare for proxied traffic, which hides the version from the internet but not from anyone who reaches the origin IP directly, so still apply the origin fix.
Where this fits
Server version disclosure is check 8 of 13 that the website vulnerability scanner runs under http security headers, ordered the way they are worth fixing. That ordering is the point: Fixing this one while the check above it still fails buys less than it looks like.
Fix this one first
Above it in the same category sits Referrer-Policy (low), where no Referrer-Policy is set, or it is set to a value that sends full URLs to other sites. An attacker who has that does not need this, so it is the better use of the same hour.
What fixing this still leaves open
Server version disclosure closes one route in. Immediately below it: X-Content-Type-Options: nosniff, where responses lack X-Content-Type-Options: Nosniff, so browsers may guess a content type and execute a file as script or style when the server said it was something else; X-Powered-By technology disclosure, where an X-Powered-By or similar header announces the application platform and often its version (PHP/8.1.2, ASP.NET, Express), narrowing an attacker's search for applicable exploits; Cache-Control on pages that set cookies, where a response that sets cookies, and is therefore personalised, does not tell caches to keep out.
Found in the same scan
The website vulnerability scanner reports this alongside checks from other categories that are at least as serious, including Certificate chain and hostname validation, where the certificate presented for this hostname did not validate: The chain does not reach a trusted root, an intermediate is missing, the name does not match, or the certificate is self-signed or expired, and Exposed .env configuration file, where a .env configuration file is served from the web root. A single run of website vulnerability scanner answers all of them at once.
The first few lines
You are a senior web engineer. I ran a security and SEO scanner against my site and it reported the finding below. Fix it properly rather than suppressing the symptom.
Finding: Server version disclosure (low severity)
Scanner check id: server-header-disclosureThe rest of this prompt names the pages and line numbers we found the problem on, the configuration to change, and the constraints a good answer has to respect. It is free, it just needs an account so the work is not scraped wholesale.
Sign in with GoogleSigning in is free and takes one click. We store your email address and nothing else.
