How to remove the IIS Server header including Microsoft-HTTPAPI/2.0.

Why this header keeps appearing in VAPT reports

Almost every web application penetration test of a Windows-hosted application lists a finding like this:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/10.0
X-Powered-By: ASP.NET
X-AspNet-Version: 4.0.30319

And when the tester sends a malformed request, or a request with a host name the server does not recognise, a second variant appears:

HTTP/1.1 400 Bad Request
Content-Type: text/html; charset=us-ascii
Server: Microsoft-HTTPAPI/2.0

Each of these headers is an information disclosure issue, normally rated informational to low. It tells anyone scanning the internet that you run IIS, roughly which Windows version, and that ASP.NET is in use. The OWASP Web Security Testing Guide treats web server fingerprinting as the first step of reconnaissance, because it tells an attacker which known weaknesses to try first.

Teams often fix the first header, see the second one in the re-test, and assume their fix failed. It did not. The two headers come from different layers of Windows, and each needs its own fix.

Where each header comes from

Server: Microsoft-IIS/10.0

Added by IIS for requests it processes. Removed with request filtering (IIS 10) or URL Rewrite (older IIS).

Server: Microsoft-HTTPAPI/2.0

Added by HTTP.sys for responses it generates itself, or when no Server header is provided. Removed with the DisableServerHeader registry value.

X-Powered-By: ASP.NET

A custom header defined in IIS configuration. Removed in customHeaders.

X-AspNet-Version

Added by ASP.NET on the .NET Framework. Removed with httpRuntime enableVersionHeader.

X-AspNetMvc-Version

Added by ASP.NET MVC 5 and earlier. Removed in Application_Start.

HTTP.sys is the kernel-mode HTTP listener in Windows. IIS sits on top of it, and so do other Windows components and self-hosted services. HTTP.sys answers some requests before IIS ever sees them: requests with invalid syntax, oversized headers or an unknown host name produce a 400, and requests for an application pool that is stopped or failing produce a 503. Those responses carry Microsoft-HTTPAPI/2.0. You will also see it on services that use HTTP.sys directly without IIS, such as WinRM on ports 5985 and 5986, Windows Admin Center, some WCF self-hosted services, SQL Server Reporting Services and ASP.NET Core applications hosted on the HTTP.sys server.

Step 1: Remove the IIS Server header (IIS 10)

On Windows Server 2019, Windows Server 2022, Windows Server 2025 and Windows Server version 1709 or later, IIS can suppress its own Server header through request filtering. Microsoft’s request filtering reference describes removeServerHeader: “If set to true, request filtering will suppress the IIS server header.” The default is false.

Set it for the whole server so every site inherits it:

# Run in an elevated PowerShell session
Import-Module WebAdministration
Set-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' `
  -Filter 'system.webServer/security/requestFiltering' `
  -Name 'removeServerHeader' -Value $true

Or with appcmd:

%windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/security/requestFiltering /removeServerHeader:true /commit:apphost

Or per site in web.config:

<configuration>
  <system.webServer>
    <security>
      <requestFiltering removeServerHeader="true" />
    </security>
  </system.webServer>
</configuration>

Step 2: Remove Microsoft-HTTPAPI/2.0 (HTTP.sys)

This header ignores everything in IIS configuration, because IIS is not involved in those responses. HTTP.sys reads its behaviour from the registry. Microsoft’s HTTP.sys registry reference documents the DisableServerHeader value:

Set it to 2:

# Elevated PowerShell
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\HTTP\Parameters' `
  -Name 'DisableServerHeader' -PropertyType DWord -Value 2 -Force

Or with reg.exe:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters" /v DisableServerHeader /t REG_DWORD /d 2 /f

Microsoft notes that registry changes “will not take effect until you restart the HTTP service”. Stopping HTTP also stops the services that depend on it, including the Windows Process Activation Service and the World Wide Web Publishing Service, so restart them afterwards, or simply reboot during a maintenance window:

net stop http /y
net start http
net start was
net start w3svc

Step 3: Remove X-Powered-By and the ASP.NET version headers

These headers are not added by HTTP.sys, so they need separate settings.

X-Powered-By: ASP.NET is a custom header inherited from the server configuration. Remove it server-wide:

Remove-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' `
  -Filter 'system.webServer/httpProtocol/customHeaders' `
  -Name '.' -AtElement @{ name = 'X-Powered-By' }

Or per site in web.config:

<system.webServer>
  <httpProtocol>
    <customHeaders>
      <remove name="X-Powered-By" />
    </customHeaders>
  </httpProtocol>
</system.webServer>

X-AspNet-Version comes from ASP.NET on the .NET Framework. Turn it off in the application’s web.config:

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

X-AspNetMvc-Version comes from ASP.NET MVC. Disable it when the application starts:

// Global.asax.cs
protected void Application_Start()
{
    MvcHandler.DisableMvcResponseHeader = true;
    // existing startup code
}

Older IIS versions (8.5 and earlier)

On Windows Server 2012 R2 and earlier, removeServerHeader does not exist. The usual workaround is an outbound rule in the URL Rewrite module that blanks the header value:

<system.webServer>
  <rewrite>
    <outboundRules rewriteBeforeCache="true">
      <rule name="Blank Server header">
        <match serverVariable="RESPONSE_Server" pattern=".+" />
        <action type="Rewrite" value="" />
      </rule>
    </outboundRules>
  </rewrite>
</system.webServer>

This leaves an empty Server: header rather than removing it, which scanners treat as resolved. It only applies to responses that pass through IIS, so you still need the HTTP.sys registry value from step 2.

Stop HTTP.sys answering unknown host names

Removing the Server header from HTTP.sys responses is only half of the clean-up for unknown host names. The body of HTTP.sys’s own error page is also recognisable: a short HTML page headed “Bad Request - Invalid Hostname” with the text “HTTP Error 400. The request hostname is invalid.” Anyone who has tested Windows servers knows that page on sight, so it fingerprints the platform even without a header.

The fix is to make IIS, not HTTP.sys, answer those requests:

Requests with unknown host names then reach IIS, which returns your neutral page with no version headers. HTTP.sys still answers truly malformed requests, which is why the DisableServerHeader registry value remains necessary.

Check every server in your estate

Fixing one server by hand is easy. The finding usually comes back because a new server was built from an old image, or a configuration management run reset the setting. This PowerShell script reports both settings across a list of servers, so you can prove the fix is in place everywhere:

# Requires PowerShell remoting to the target servers
$servers = Get-Content .\iis-servers.txt

Invoke-Command -ComputerName $servers -ScriptBlock {
    Import-Module WebAdministration -ErrorAction SilentlyContinue
    $http = Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\HTTP\Parameters' -ErrorAction SilentlyContinue
    $rf   = Get-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' `
              -Filter 'system.webServer/security/requestFiltering' -Name 'removeServerHeader' -ErrorAction SilentlyContinue
    $xpb  = Get-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' `
              -Filter "system.webServer/httpProtocol/customHeaders/add[@name='X-Powered-By']" -Name 'value' -ErrorAction SilentlyContinue
    [pscustomobject]@{
        Server              = $env:COMPUTERNAME
        DisableServerHeader = $http.DisableServerHeader
        RemoveServerHeader  = $rf.Value
        XPoweredByPresent   = [bool]$xpb
    }
} | Select-Object Server, DisableServerHeader, RemoveServerHeader, XPoweredByPresent | Format-Table -AutoSize

A healthy server shows DisableServerHeader as 2, RemoveServerHeader as True and XPoweredByPresent as False. Site-level web.config files can still override the server-level settings, which is why the external curl checks below remain the final word.

Microsoft products that run on IIS

Exchange Server (Outlook on the web), Active Directory Federation Services, SharePoint, Windows Server Update Services and Remote Desktop Web Access all run on IIS or HTTP.sys and appear in the same findings. The same two layers apply, but take extra care:

ASP.NET Core applications

How you remove the header depends on how the app is hosted:

For Kestrel:

var builder = WebApplication.CreateBuilder(args);
builder.WebHost.ConfigureKestrel(options => options.AddServerHeader = false);

Azure and load balancers in front of IIS

If IIS sits behind Azure Application Gateway, Azure Front Door, a hardware load balancer or a CDN, check the response at the edge as well. Some of these add their own Server header, and some pass through whatever IIS sends. The header a scanner sees is the one at the public edge. If your IIS servers are behind an AWS Application Load Balancer, the load balancer also adds its own header; our guide to removing the AWS ALB server header covers that.

Verify the fix

Test both a normal request and requests that HTTP.sys answers itself. A malformed request is the easiest way to make HTTP.sys reply directly:

# 1. Normal request: no Server, X-Powered-By or X-AspNet* headers
curl -sI https://legacy.example.com/ | grep -iE '^(server|x-powered-by|x-aspnet)'

# 2. Unknown host name: answered by HTTP.sys when no site binding matches
curl -sI https://legacy.example.com/ -H "Host: not-a-real-site.invalid" -k | grep -i '^server'

# 3. Malformed request, also answered by HTTP.sys
printf 'GET / HTTP/1.1\r\nHost: legacy.example.com\r\nBad Header Line\r\n\r\n' \
  | timeout 5 openssl s_client -quiet -connect legacy.example.com:443 2>/dev/null | grep -i '^server'

From Windows, PowerShell gives the same answer for normal requests:

(Invoke-WebRequest -Uri 'https://legacy.example.com/' -Method Head -UseBasicParsing).Headers

The rest of your IIS hardening checklist

While you have a change window open, these are the IIS findings we see most often after the Server header:

Does hiding the Server header actually make you safer?

It is a fair question, and the honest answer is: a little, and mostly indirectly.

Removing version headers does not fix any vulnerability. A skilled attacker can still identify IIS from the shape of error pages, the order of response headers, cookie names such as ASP.NET_SessionId, .aspx URLs and how the server handles unusual requests. If your server is missing patches, hiding its name does not make it patched.

What it does change:

The right way to think about it: remove the headers because it is cheap and expected, and spend the real effort on patching, TLS configuration, authentication and the application itself. That is where penetration tests find the issues that matter.

Why it matters for audits

Version disclosure is a small finding, but it is visible in every external scan and it appears in enterprise security questionnaires and supplier assessments. For SOC 2 and ISO 27001 assessments, it is evidence of whether server hardening is actually applied, which is why it is worth closing before a re-test rather than accepting it as a risk.