How to remove IIS/ASP.NET Response Headers
Solution 1:
To remove all custom headers that disclose too much information - the methods are varied (unfortunately) for IIS 7:
Header Name: X-Powered-By
Add:
<httpProtocol>
<customHeaders>
<remove name="X-Powered-By" />
</customHeaders>
</httpProtocol>
in the <system.webServer> section.
Header Name: Server
Implement an httpModule that strips this header out by calling Response.Headers.Remove("Server") from the PreSendRequestHeaders event. Another resource for this: Cloaking your ASP.NET MVC Web Application on IIS 7
Header Name: X-AspNet-Version
In the httpRuntime section of the web.config - set:
<httpRuntime enableVersionHeader="false" />
Header Name: X-AspNetMvc-Version
From the Application_Start event in global.asax - execute the following code (C#):
MvcHandler.DisableMvcResponseHeader = true;
Solution 2:
Your security department wants you to do this to make the server type harder to identify. This may lessen the barrage of automated hacking tools and make it more difficult for people to break into the server.
Within IIS, open the web site properties, then go to the HTTP Headers tab. Most of the X- headers can be found and removed here. This can be done for individual sites, or for the entire server (modify the properties for the Web Sites object in the tree).
For the Server header, on IIS6 you can use Microsoft's URLScan tool to remote that. Port 80 Software also makes a product called ServerMask that will take care of that, and a lot more, for you.
For IIS7 (and higher), you can use the URL Rewrite Module to rewrite the server header or blank it's value. In web.config (at a site or the server as a whole), add this content after the URL Rewrite Module has been installed:
<rewrite>
<outboundRules rewriteBeforeCache="true">
<rule name="Remove Server header">
<match serverVariable="RESPONSE_Server" pattern=".+" />
<action type="Rewrite" value="" />
</rule>
</outboundRules>
</rewrite>
You can put a custom value into the rewrite action if you'd like. This sample sourced from this article which also has other great information.
For the MVC header, in Global.asax:
MvcHandler.DisableMvcResponseHeader = true;
Edited 11-12-2019 to update the IIS7 info since the TechNet blog link was no longer valid.
Solution 3:
Putting this in an ASP.NET application's web.config file will get rid of the X-AspNet-Version header:
<system.web>
<httpRuntime enableVersionHeader="false" />
</system.web>
Note that the system.web tag should already exist in the file. Don't create a duplicate, just add the httpRuntime tag. The httpRuntime tag might also already exist. If so, just add the attribute or set its value if it's already there.
Solution 4:
Having just been through the "hardening" cycle on my current project - I blogged about the approach we took, which includes a HTTPModule for removing the following headers:
Server,
X-AspNet-Version,
X-AspNetMvc-Version,
X-Powered-By
Pertinent pieces reproduced below:
But there is no easy way to remove the Server response header via configuration. Luckily IIS7 has a managed pluggable module infrastructure which allows you to easily extend its functionality. Below is the source for a HttpModule for removing a specified list of HTTP Response Headers:
namespace Zen.Core.Web.CloakIIS
{
#region Using Directives
using System;
using System.Collections.Generic;
using System.Web;
#endregion
/// <summary>
/// Custom HTTP Module for Cloaking IIS7 Server Settings to allow anonymity
/// </summary>
public class CloakHttpHeaderModule : IHttpModule
{
/// <summary>
/// List of Headers to remove
/// </summary>
private List<string> headersToCloak;
/// <summary>
/// Initializes a new instance of the <see cref="CloakHttpHeaderModule"/> class.
/// </summary>
public CloakHttpHeaderModule()
{
this.headersToCloak = new List<string>
{
"Server",
"X-AspNet-Version",
"X-AspNetMvc-Version",
"X-Powered-By",
};
}
/// <summary>
/// Dispose the Custom HttpModule.
/// </summary>
public void Dispose()
{
}
/// <summary>
/// Handles the current request.
/// </summary>
/// <param name="context">
/// The HttpApplication context.
/// </param>
public void Init(HttpApplication context)
{
context.PreSendRequestHeaders += this.OnPreSendRequestHeaders;
}
/// <summary>
/// Remove all headers from the HTTP Response.
/// </summary>
/// <param name="sender">
/// The object raising the event
/// </param>
/// <param name="e">
/// The event data.
/// </param>
private void OnPreSendRequestHeaders(object sender, EventArgs e)
{
this.headersToCloak.ForEach(h => HttpContext.Current.Response.Headers.Remove(h));
}
}
}
Ensure that you sign the assembly, then you can install it into the GAC of your web servers and simply make the following modification to your application’s web.config (or if you want it to be globally applied, to the machine.config):
<configuration>
<system.webServer>
<modules>
<add name="CloakHttpHeaderModule"
type="Zen.Core.Web.CloakIIS.CloakHttpHeaderModule, Zen.Core.Web.CloakIIS,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=<YOUR TOKEN HERE>" />
</modules>
</system.webServer>
</configuration>
Solution 5:
Check this blog. Don't use code to remove response headers. It is unstable according Microsoft
Use the Web.config custom Headers section instead:
<system.webServer>
<httpProtocol>
<!-- Security Hardening of HTTP response headers -->
<customHeaders>
<!--Sending the new X-Content-Type-Options response header with the value 'nosniff' will prevent
Internet Explorer from MIME-sniffing a response away from the declared content-type. -->
<add name="X-Content-Type-Options" value="nosniff" />
<!-- X-Frame-Options tells the browser whether you want to allow your site to be framed or not.
By preventing a browser from framing your site you can defend against attacks like clickjacking.
Recommended value "x-frame-options: SAMEORIGIN" -->
<add name="X-Frame-Options" value="SAMEORIGIN" />
<!-- Setting X-Permitted-Cross-Domain-Policies header to “master-only” will instruct Flash and PDF files that
they should only read the master crossdomain.xml file from the root of the website.
https://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html -->
<add name="X-Permitted-Cross-Domain-Policies" value="master-only" />
<!-- X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers.
Recommended value "X-XSS-Protection: 1; mode=block". -->
<add name="X-Xss-Protection" value="1; mode=block" />
<!-- Referrer-Policy allows a site to control how much information the browser includes with navigations away from a document and should be set by all sites.
If you have sensitive information in your URLs, you don't want to forward to other domains
https://scotthelme.co.uk/a-new-security-header-referrer-policy/ -->
<add name="Referrer-Policy" value="no-referrer-when-downgrade" />
<!-- Remove x-powered-by in the response header, required by OWASP A5:2017 - Do not disclose web server configuration -->
<remove name="X-Powered-By" />
<!-- Ensure the cache-control is public, some browser won't set expiration without that -->
<add name="Cache-Control" value="public" />
</customHeaders>
</httpProtocol>
<!-- Prerequisite for the <rewrite> section
Install the URL Rewrite Module on the Web Server https://www.iis.net/downloads/microsoft/url-rewrite -->
<rewrite>
<!-- Remove Server response headers (OWASP Security Measure) -->
<outboundRules rewriteBeforeCache="true">
<rule name="Remove Server header">
<match serverVariable="RESPONSE_Server" pattern=".+" />
<!-- Use custom value for the Server info -->
<action type="Rewrite" value="Your Custom Value Here." />
</rule>
</outboundRules>
</rewrite>
</system.webServer>