Secure Sitecore : Headers are a headache but nothing we cannot solve!

Lately I have been focussed on OWASP Top 10 security guidelines and locking down sites. The next one on the list is Response Headers. For reach page request, the server sends over the headers containing information about the server and ASP.NET. Some call it chatty headers and less we send back the better it is to protect ourselves.

There are several things you could do to secure your Sitecore instance, namely the Sitecore Security Hardening Guide. Along with the documented steps, there are several others you should implement to secure your instances.

header1

Thank goodness in the newer versions of Sitecore they tackled two of these by default, namely the X-Powered-By:

and X-AspNet-Version (enableVersionHeader as false):

header2

Next for the X-AspNetMvc-Version HTTP Header, we need to add the following in the Global.asax:

header4

Last but not the least is the Server header. In order to take this guy out we could add on to the Global.asax, here is the sample code:

header5

But where is the fun in that! I usually do not like to fiddle with the Global.asax and so this is an alternate solution to the two fixes above which require Global.asax. This fix relies on defining an Http Module. Lets start by defining a class which inherits IHttpModule:

Following which lets add it into the Modules section of system.webServer to register the module.

Both yield the same results, one is cleaner than the other.

If you have any questions or concerns, please get in touch with me. (@akshaysura13 on twitter or on Slack).

Http Module inspiration from IIS 7 – How to send a custom “Server” http header.

no comment

Add your comment

Your email address will not be published.