How to Prevent Information Disclosure in HTTP Headers

What is Information Disclosure?#

Information disclosure happens when your web server includes HTTP response headers that reveal details about the software it runs, the framework behind your application, or the infrastructure powering your site. Every time a browser requests a page, your server sends back these headers alongside the content. If those headers contain version numbers, platform names, or internal hostnames, anyone can read them simply by inspecting the response.

This matters because attackers use this information for reconnaissance, the first phase of most targeted attacks. When a server header says "Apache/2.4.49" or a framework header says "Express," the attacker immediately knows which CVEs (Common Vulnerabilities and Exposures, publicly disclosed security flaws) to look up. Instead of probing blindly, they can search databases like the National Vulnerability Database for exploits specific to that exact version, dramatically reducing the effort needed for a successful attack.

Removing these headers does not fix underlying vulnerabilities, but it forces attackers to spend significantly more time and effort on discovery. Combined with keeping your software up to date and implementing other security headers, information disclosure prevention is an important layer in a defense-in-depth strategy.

• Removes details that help attackers plan targeted exploits
• Forces attackers to probe blindly instead of using known vulnerabilities
• Required by security frameworks like PCI DSS and CIS Benchmarks
• Easy to implement with minimal risk of breaking functionality

Common Information Disclosure Headers#

Information disclosure headers fall into several categories based on what they reveal. Understanding these categories helps you audit your own server and identify which headers need to be removed.

Why Information Disclosure Is Dangerous#

Exposing server details through HTTP headers gives attackers a roadmap for targeted exploitation. Here is a real-world example of how this works in practice.

This pattern repeats across every type of information disclosure. When headers reveal your CMS is WordPress 5.8, attackers look up WordPress 5.8 vulnerabilities. When they see your PHP version, they check for PHP-specific exploits. Each piece of information narrows the attack surface from the attacker's perspective and makes their job easier.

• Enables targeted attacks using known CVEs for specific software versions
• Reveals your technology stack, making it easier to chain vulnerabilities across layers
• Exposes internal hostnames and infrastructure topology through backend headers
• Automated scanning tools specifically look for these headers to build attack profiles

How to Remove These Headers#

The approach for removing information disclosure headers varies by server and platform. Below are configurations for the most common web servers and application frameworks.

Apache

# Add to httpd.conf or .htaccess

# Minimize the Server header (cannot fully remove in Apache,
# but ServerTokens Prod reduces it to just "Apache")
ServerTokens Prod
ServerSignature Off

# Remove framework and application headers
Header unset X-Powered-By
Header unset X-AspNet-Version
Header unset X-AspNet-MVC-Version
Header unset X-Runtime
Header unset X-Version
Header unset X-Generator
Header unset X-Drupal-Cache
Header unset X-PHP-Version
Header unset X-PHP-Originating-Script

Nginx

# Add to nginx.conf or site configuration

# Hide Nginx version from Server header
server_tokens off;

# Remove application and framework headers
# (requires the headers-more module)
more_clear_headers 'X-Powered-By';
more_clear_headers 'X-AspNet-Version';
more_clear_headers 'X-Runtime';
more_clear_headers 'X-Version';
more_clear_headers 'X-Generator';
more_clear_headers 'Server';

Node.js / Express

// Express automatically sends X-Powered-By: Express
// Disable it with one line:
app.disable('x-powered-by');

// Or use Helmet, which removes it by default
// and adds other security headers:
const helmet = require('helmet');
app.use(helmet());

// To remove additional custom headers:
app.use((req, res, next) => {
  res.removeHeader('X-Runtime');
  res.removeHeader('X-Version');
  next();
});

IIS (Internet Information Services)

<!-- Add to web.config -->
<system.webServer>
  <httpProtocol>
    <customHeaders>
      <remove name="X-Powered-By" />
      <remove name="X-AspNet-Version" />
      <remove name="X-AspNetMvc-Version" />
    </customHeaders>
  </httpProtocol>
  <security>
    <requestFiltering removeServerHeader="true" />
  </security>
</system.webServer>

<system.web>
  <httpRuntime enableVersionHeader="false" />
</system.web>

Testing and Verification#

After configuring your server, verify that information disclosure headers have been removed. Use multiple methods to ensure nothing is being leaked at any layer.

Command Line with curl

The simplest way to inspect response headers is with curl. The -I flag sends a HEAD request and shows only the response headers.

# Check response headers
curl -I https://your-site.com

# Look specifically for information disclosure headers
curl -sI https://your-site.com | grep -iE "server|x-powered|x-aspnet|x-php|x-generator|x-runtime|x-version|x-backend|x-framework|x-cms|x-panel|platform"

Browser Developer Tools

Open your browser's Developer Tools (F12), navigate to the Network tab, reload the page, and click on the main document request. The Response Headers section will show all headers your server is sending, including any information disclosure headers that need to be removed.

Automated Scanning

Use SiteSecurityScore to scan your website for information disclosure headers automatically. The scanner checks for all common disclosure headers and flags any that are still present, so you do not have to remember the full list yourself.

Best Practices#

Removing information disclosure headers is just one part of a broader security strategy. Follow these practices to maintain a strong security posture over time.

For a full list of information disclosure headers that SiteSecurityScore checks for, see the Advanced Security Headers reference page. You can also learn more about the OWASP Secure Headers Project, which maintains an up-to-date list of recommended security headers.