Server Banner Exposure Checker

See exactly which software names and version numbers a site volunteers in its response headers, and get the configuration lines that stop it.

Passive public check

a2z.tools reads publicly visible information from the address you enter. It is a read-only request - nothing is submitted, changed or probed.

Address to check Reads the response headers of a public page.

What your server volunteers about itself

Most web servers announce what they are in every response. Server: nginx/1.18.0, X-Powered-By: PHP/7.4.3, X-AspNet-Version: 4.0.30319. Nobody asked; the default configuration simply says so. This tool reads those headers and tells you which of them carry a version number.

The honest assessment of why this matters

Removing a version banner patches nothing. If a host is running a vulnerable version, it is vulnerable whether or not it says so, and anyone specifically targeting you will fingerprint it another way - behaviour, error pages, header ordering and TLS characteristics all leak the same information to someone determined enough.

What the banner changes is your exposure to the untargeted half. After a disclosure, automated scanning sweeps the internet looking for the affected version string, and services like Shodan and Censys make that search trivial. A precise version in a header is what puts a host into those result sets. Removing it does not make you secure; it takes you out of the list that gets tried first, and it costs one configuration line.

This is why the tool reports a version banner as low severity and a name without a version as informational. Knowing a site runs Nginx narrows nothing - it is one of two answers for most of the web. Knowing it runs nginx/1.18.0 tells someone exactly which advisories to read.

What gets checked

Server, X-Powered-By, X-AspNet-Version, X-AspNetMvc-Version, X-Generator, X-Drupal-Cache and X-Runtime. Each has its own suppression setting, so the fix is shown per header rather than as one piece of generic advice.

X-Runtime is worth a separate mention: as well as naming the platform, it reports how long the request took, which in some circumstances contributes to a timing side channel. It is rarely needed in production.

What to do instead of nothing

Suppress the versions, then treat that as the smallest part of the job. The thing that actually protects a host is knowing what it runs and keeping it current. Use Website Technology Checker to see what else is detectable about the stack, and Dependency End-of-Life Checker to find out whether the versions you are running are still supported at all - an unsupported runtime is a far bigger problem than a header that names it.

Limitations

This reads headers on one response. It cannot see software that does not announce itself, it cannot tell whether a version is genuine - a proxy can send whatever it likes - and a suppressed banner does not mean a host is unidentifiable. Fingerprinting by behaviour is beyond what a passive header check can do, and beyond what these tools do at all.

Frequently asked questions

Is hiding the version actually worth doing?

It is worth one configuration line and no more effort than that. It does not make you secure and it will not stop a targeted attacker, but it removes you from automated searches for a specific version string, which is how most opportunistic scanning selects targets.

Is this security through obscurity?

Partly, and that is fine as long as it is not the only measure. Obscurity is a poor foundation and a reasonable top layer. The tool deliberately rates it low severity so it does not crowd out work that matters more.

My server shows a name but no version. Should I remove it too?

Generally not worth it. Knowing a site runs Nginx or Apache tells an attacker almost nothing they would not assume anyway, and some load balancers and monitoring tools expect the header to exist.

Could the version shown be wrong?

Yes. A reverse proxy, CDN or WAF can rewrite these headers, so the value may describe the edge rather than the origin, or be entirely synthetic. Treat it as what the site claims rather than what it runs.

References

Related tools

What this tool can and cannot tell you. It reports the configuration a site exposes to an ordinary visitor. It does not log in, submit anything, or test for vulnerabilities, so a passing result means the public configuration looked correct at the moment of the check - not that the site is secure.

Security guidance here follows current published sources - OWASP, MDN, the relevant RFCs, NIST, CISA, FIRST and MITRE - which are linked beside the specific claims they support.