Remove HTTP Response Headers for internet facing SharePoint sites

if you are serious about to publish an internet facing SharePoint site you have to consider security. One of the first things a possible hacker will inspect are the HTTP Response Headers. I usually use the Firefox Developper toolbar to check the HTTP Response Headers of my SharePoint sites. (Information Menu -> View Response Headers)

Without cleaning the reponse headers you will see something like:

Connection: Keep-Alive
Expires: Mon, 23 May 2011 13:56:12 GMT
Date: Tue, 07 Jun 2011 13:56:13 GMT
Content-Type: text/html; charset=utf-8
<strong>Server: Microsoft-IIS/7.5</strong>
Cache-Control: private, max-age=0
Last-Modified: Tue, 07 Jun 2011 13:56:12 GMT
<strong>SPRequestGuid: 2ba6c04a-f3ca-40be-a543-7fb2448bd92e
X-SharePointHealthScore: 0
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
Transfer-Encoding: chunked
Content-Encoding: gzip
Vary: Accept-Encoding

200 OK

Now, what I needed removing was all the SharePoint stuff, the ASP.NET stuff and the server information (marked in bold). Luckily I was not the first guy out there to do so and I used Stefan Go├čner’s post ( as a lead to achieve what I wanted.

I ended up creating a custom HttpModule for removing the excess information in combination with adding a section to the web.config for the custom Headers added by SharePoint as they were not removed by the HttpModule after my initial testing.

Actions performed:
1. Create a folder named App_Code in the IIS folder of the SharePoint site where the headers need to be removed
2. Create a file with notepad named CustomHttpModule.cs
3. Edit with notepad:

using System;
using System.Text;
using System.Web; 

namespace Custom.ServerModules
  public class CustomHttpHeaderModule : IHttpModule
    public void Init(HttpApplication context)
      context.PreSendRequestHeaders += OnPreSendRequestHeaders;
    public void Dispose()
    void OnPreSendRequestHeaders(object sender, EventArgs e)

4. Save the file
5. Edit the web.config file of the SharePoint web application
– Add the custom module to the section system.webserver
– have the custom headers removed

  <modules runAllManagedModulesForAllRequests="true">
    <add name="CustomHttpModule" type="Custom.ServerModules.CustomHttpHeaderModule" />
      <remove name="MicrosoftSharePointTeamServices" />
      <remove name="X-Powered-By" />

One remark though if you implement this. Removing the header MicrosoftSharePointTeamServices may break your search crawling. In my case I usually dedicate a web front end for crawling or have the Web application role activated on the crawler. Evidently this web front end does not get the custom httpmodule.

6 thoughts on “Remove HTTP Response Headers for internet facing SharePoint sites

  1. If you remove MicrosoftSharePointTeamServices from the header, you will break the ability to update Office documents via the office application or refresh data from a library within the office application eg…

    Export to Excel from a list
    Update a list from Sharepoint
    Click the refresh button from Excel


    A connection to the SharePoint site cannot be established. To synchronize or refresh your table, you must be able to connect to the SharePoint site.

  2. Hi Rob,

    you are absolutely right, but remember the idea was to remove all SharePoint related tags for a public and anonymous internet facing site, so editing of office documents is not a requirement in that scenario. If this is required, you can implement a reverse proxy that allows for authentication and define for that reverse proxy that it communicates with a web front end that does not have the headers removed. And then again we are more entering an extranet scenario where I would not recommend removing header information.

    best regards

    • Hi,

      as I am not a developer I cannot give you any guidance as to how to package these modifications into a SharePoint solution. I am pretty sure it can be done as these modifications include settings in the web.config file and the IIS folder file.

      best regards,

  3. Indeed, that should be all you need to do to get the module to work.

    I would wrap this up though in a solution that deploys the DLL to the GAC, and a Farm-scoped Feature with Receiver Code that injects the required lines into web.config using SPWebConfigModification.

    You could do it manually, but if you have multiple web front ends, this method will ensure the are all synchronised and have the exact same changes made to all of them.

    Plus, uninstallation is easier (you just need deactivation code to remove the lines from webconfig, again using SPWebConfigModification). And when you retract the solution, it’ll remove the DLL from the GAC for you. Again, all of this is synchronised across all your web front ends.

Leave a Reply

Your email address will not be published. Required fields are marked *