Server header security is overlooked on almost every small-business WordPress site. During recent website security scans, just 1.3% of sites had the server banner fully hardened against version or software disclosure. The rest give away their infrastructure with every HTTP response—often including the exact server type and sometimes the version number.
This means the overwhelming majority of WordPress sites are making it easy for automated scripts and threat actors to quickly profile their environment. Not only does this increase the odds of a targeted exploit, but it also defeats basic obscurity—removing one low-effort hurdle for opportunistic attacks.
Even sites that take care of SSL, cookies, or mixed content often ignore the server header, misunderstanding what’s really at stake.
What Exposing Your Server Banner Means
A “server banner” is the snippet your web server sends to browsers (and bots) in the HTTP response header. Typical examples look like this:
Server: Apache/2.4.54 (Unix)
Server: nginx/1.23.3
Server: openresty
By default, Apache and Nginx both reveal their names and, by default, the exact version number. This information is available on every public request—even for unauthenticated visitors.
For attackers, this acts as a search filter. Combined with a database of known vulnerabilities (often called “Common Vulnerabilities and Exposures,” or CVEs), exposed server versions allow attackers to identify which sites are potentially vulnerable to specific exploits—all without touching anything behind a login. For example, CVE-2021-41773 affected Apache HTTP Server 2.4.49 and 2.4.50: version disclosure made it trivial for automated tools to pinpoint at-risk servers.
Profiling by server header is proven, not theoretical. Automated vulnerability scanners—including legitimate and malicious ones—use server banner information as the first sorting mechanism for mass exploitation campaigns.
What We Measured
The numbers below come from automated grade-based security scans targeting real, live small-business WordPress sites. Here’s how the server header check works: a site is rated as “Good” only if the server banner does not advertise its software type or version in the HTTP header. All others receive a failing grade.
This failure isn’t limited to poorly maintained sites. Even those with valid SSL certificates or strong cookie protections often miss this check.
Server Banner Security: Check Rate Table
| Check | % Rated Good | % Failing |
|---|---|---|
| Server Banner (no version leak) | 1.3% | 98.7% |
Scan window: Last 30 days
Sample size: 20,174 measured sites (from 87,601 total scans across 72,324 unique sites; only sites returning a server banner header were included in this check rate).
Full Grade Distribution (Sample: 87,601 scans across 72,324 unique small-business WordPress sites)
| Grade | Graded Scans | Percentage |
|---|---|---|
| A | 365 | 0.4% |
| B+ | 1,359 | 1.6% |
| B | 790 | 0.9% |
| C+ | 18,322 | 20.9% |
| C | 8,940 | 10.2% |
| D | 21,431 | 24.5% |
| F | 27,396 | 31.3% |
Server banner exposure correlates strongly with lower overall security grades.
The Numbers
- In the last 30 days, 98.7% of 20,174 measured WordPress sites failed the server banner security check.
- Only 1.3% had no identifying information in the server header.
- 20.5% of all scanned WordPress sites explicitly leaked their web server version—a direct match for rapid exploit targeting.
Server banner exposure is the norm, not the exception. The vast majority of WordPress sites—regardless of SSL, cookie policy, or mixed content status—still advertise server software details.
Why This Isn’t Just “Obscurity”
Some argue that hiding server headers is “security through obscurity.” The numbers, and real-world attack chains, disagree.
Real attack data shows that opportunistic attacks start by fingerprinting a site: they use exposed server banners to prioritize which targets to probe further. In 2021, Apache's CVE-2021-41773 demonstrated how version leakage led to a surge in targeted scanning and exploitation for two popular Apache versions. Tools like WPScan and Metasploit modules use this banner as an “if statement”—if a known-vulnerable version is detected, automated exploitation scripts run next.
You may not be running a vulnerable version, but by leaving the door open for rapid reconnaissance, you’re in the default group sifted by attackers first.
Obscuring the server header is not a replacement for patches or real security controls, but it’s a measurable way to reduce automated targeting. Think of it as removing a “rob this house” sign from your front yard—not foolproof, but it’s unwise to leave it there.
Where the Real-World Risk Comes From
This configuration gap creates avoidable exposure. On its own, leaking a server banner does not compromise your data or grant unauthorized access. But combined with unpatched software, misconfigured plugins, or publicly known vulnerabilities, it’s the missing puzzle piece.
Widespread bot traffic constantly indexes headers and looks for weak points. If your server banner matches a version with a CVE issued in the last year, your likelihood of targeted automated scanning rises sharply. In active attacks observed across the WordPress ecosystem, version exposure is a consistent first step.
What to Watch Out For
WordPress security isn’t just plugins and logins. Server banner security is about shrinking your site’s attack surface at the point of first contact.
Other checks, such as full SSL/TLS hardening or security headers, require more significant changes and deeper technical work. Hardening your server banner is a focused action that reduces trivial information leaks without affecting your site’s functionality or user experience.
If you’re unsure whether your server is giving away details, a website security scan will give a clear pass/fail on this exact issue—no guesswork needed. Find more on what these scans check in our features breakdown.
The Fix
You can address server banner exposure with a few targeted steps. Owners and agencies can typically implement these in under 30 minutes per site.
- Check your headers: Use an external tool to view your HTTP response headers. Look for the “Server” line—does it show “Apache,” “nginx,” “IIS,” or detailed version info?
- Configure your server to suppress the banner:
- If you host on Apache, set
ServerSignature OffandServerTokens Prodin httpd.conf. - For Nginx, use
server_tokens off;in nginx.conf. - Managed hosts may require a support ticket.
- If you host on Apache, set
- Verify after changes: Rerun a website security scan to confirm the header is gone or properly generic.
- Ask your host if you cannot change server configs: If you’re on a fully managed WordPress host, request that they suppress or sanitize the “Server” header as part of their standard security hardening.
Most changes can be made in minutes once you can access server configs or work with your hosting provider. For most small-business sites, this is a low-effort, high-value hardening step.
Final Thoughts
Almost every WordPress site is sharing its infrastructure details in the open—98.7% in the last month alone. Even a strong SSL certificate and up-to-date plugins don’t close this information leak. In modern attack chains, server banner exposure makes your site an easy candidate for targeted scanning, especially when new vulnerabilities are published.
If you’re unsure how your server responds, it takes less than a minute to check: run a website security scan focussed on version and banner exposure.
Is your site among the 1.3% that keeps quiet, or does your server do the talking for you?