Your web server conveys a variety of information to the client when a visitor opens your website. They can access specific policies you've set and sometimes identify what kind of software you use to run your system. Sometimes, that's okay. Other times, the information exposed in your server header can lead directly to a malicious cyber attack.
This article provides an overview on how web servers communicate with HTTP headers, followed by risk findings that indicate whether your server information is being exposed by an overly detailed response header.
What Are Server Headers?
Every website is hosted on a web server that serves as the intermediary between the client request and the website response. When you enter a domain into your browser, you send a request to retrieve the web page identified with that URL. The web server receives the HTTP request and returns the files necessary to render the web application.
Web servers use the Hypertext Transfer Protocol (HTTP) and the Hypertext Transfer Protocol Secure (HTTPS), which are data communication protocols for the internet. Both HTTP and HTTPS exchange resources between a client and a server on the internet. However, HTTPS provides additional security measures that are not available with HTTP, such as Transport Layer Security (TLS) through the addition of SSL certificates and the HTTPS Strict-Transport-Security policy (HSTS) to enforce secure connections. These additional layers of security add authentication and validation for web communications.
In brief, the client sends an API request, to which the server sends a response. HTTP response headers relay information about the origin server to the connecting client, including redirection targets, software details, and the age of cached information. As these headers are configured on the server, you can set policies to govern what information is publicly available to the client. The syntax for HTTP headers uses a case-insensitive key-value pairing to specify the functionality.
How to Read HTTP Server Headers
You can access HTTP status codes and the full HTTP headers (both the request header and the response header) by accessing the network tab of your browser or by using [.rt-script]curl[.rt-script].
For a sample website, left click and select the Inspect option to open the developer console, then navigate to the Network tab. Refresh the page to load information, then select anything from the list to open the Headers panel. You can access information about the general request, including the request URL (the website you want to visit), the type of request (typically a [.rt-script]GET[.rt-script] request), and other details like the referrer policy. You can also read the response headers and request headers, which include headers like [.rt-script]Access-Control-Max-Age[.rt-script] to indicate cache length, [.rt-script]Content-Type[.rt-script] to indicate media resource information, [.rt-script]Content-Length[.rt-script] supplying the resource size, [.rt-script]Content-Encoding[.rt-script] to govern compression, [.rt-script]Set-Cookie[.rt-script] to send cookies to the user-agent, as well as many other headers that govern server-client communications.
To retrieve headers in the terminal, run [.rt-script]curl -v example.com[.rt-script] in your terminal to retrieve headers for the [.rt-script]example.com[.rt-script] website. The [.rt-script]-v[.rt-script] option, which you can also specify with [.rt-script]--verbose[.rt-script], will return more information. The resulting output will prepend [.rt-script]>[.rt-script] for the HTTP request headers and [.rt-script]<[.rt-script] for the response headers and site data.
Some headers set conditions to manage how web browsers like Chrome or Mozilla Firefox serve the web application, such as the [.rt-script]Access-Control-Allow-Origin[.rt-script] header for cross-origin resource sharing (CORS). For additional protection, headers like [.rt-script]X-Frame-Options[.rt-script], [.rt-script]X-XSS-Protection[.rt-script], and [.rt-script]X-Content-Type-Options[.rt-script] limit site rendering based on specific concerns around click-jacking, cross-site scripting attacks, and issues with Multipurpose Internet Mail Extension (MIME) media types.
Because information conveyed in the HTTP response header fields is publicly available to anyone who accesses your site, any sensitive information in the header expands your potential attack surface. Header information can be harvested programmatically, which makes internet traffic with public information a target for hackers.
HTTP Header Exposure Risks
By identifying your HTTP server response header exposure risk, you can implement configuration changes to limit what information is conveyed in the response header. While you can do this manually, there are a variety of tools available for automation, including UpGuard BreachSight.
In addition to a variety of HTTP-related risks, BreachSight identifies when your website headers expose server information with the following risk findings:
- Server information header exposed
- Use of ASP.NET exposed via header
- Specific ASP.NET version exposed via header
- X-Powered-By header exposed
The Server information header exposed finding identifies whether server version information is revealed in the header. If the server version is accessible, a potential attacker could exploit any vulnerabilities impacting that version. Limiting the information exposure in the header will help you narrow the possibilities for malicious hackers to exploit your system. Any knowledge pertaining to versions can be especially detrimental for systems running on older versions of software, as those versions may not receive support patches for security vulnerabilities.
Because some technologies populate the [.rt-script]server[.rt-script] header by default, protecting your system can require additional configuration to ensure that this information is removed, redacted, or limited in detail. For example, if you are using an Apache server, you cannot redact the server information entirely but you can configure the directive to send limited information or use a proxy server. Microsoft's Internet Information Services (IIS), in contrast, is an extensible web server that can be set with a URL rewrite rule to replace the header.
Because exposed header information specifies software information, BreachSight has two additional findings for ASP.NET use: Use of ASP.NET exposed via header and Specific ASP.NET version exposed via header. ASP.NET is an open source web framework compatible with most operating systems, including macOS, Linux, and Microsoft (as well as Docker containers). Default installations of the IIS web server often include the [.rt-script]X-AspNet-Version[.rt-script] and [.rt-script]X-Powered-By[.rt-script] headers, which both indicate that the web server uses ASP.NET. If this information is conveyed to the client, then your website visitor will know that ASP.NET is in use and that IIS is running on your system. Malicious attackers can leverage that information as reconnaissance to prepare for threat behaviors based on IIS and ASP.NET vulnerabilities. You can modify your settings in the IIS administrative user interface to remove the [.rt-script]X-Powered-By[.rt-script] header, set a [.rt-script]URLRewrite rule[.rt-script] for either header, or modify the [.rt-script]<system.web>[.rt-script] section of the[.rt-script]web.config[.rt-script] file to remove the [.rt-script]X-AspNet-Version[.rt-script] header.
The [.rt-script]X-Powered-By[.rt-script] header reveals information about a variety of services in use, not only ASP.NET, so BreachSight also scans for the X-Powered-By header exposed finding. Depending on the service, you may need to take additional configuration steps to limit information exposure. For example, if your server runs PHP, you will need to disable the [.rt-script]expose_php[.rt-script] setting in the [.rt-script]php.ini[.rt-script] file. Review the documentation for the technology used on your system to identify how to disable server header information that exposes system information.
Monitoring your server headers on a recurring basis can help you identify exposed header information. An automated solution for continuous monitoring ensures that you can prioritize server hardening and configuration.
How UpGuard Can Help
With UpGuard, you can feel confident that your external attack surface is continuously monitored. Our user-friendly platform provides an intuitive and convenient dashboard to help you stay informed about your cybersecurity posture and server security. Receive alerts for potential risks so you can focus your resources where they are most needed. Your domain is scanned daily to ensure real-time reporting.
To find out what kind of issues pose risks on your system, log in and access your Risk Profile. You'll be informed about the specific finding as well as any assets that are affected by the risk. For more information about other SSL/TLS and HTTP-related risks, read our posts on SSL certificate expiration, the SSL not available finding, weak SSL, misconfigured SSL, HTTPS redirection, HSTS risks, and Content Security Policy configuration.
