Azure Website 101: Enhance the security of your WebApp

When you type a website URL in browser and hit enter, your browser start rendering that particular site for you. Most of the people think requesting a particular site only involves fetching the appropriate page from server and rendering those information with proper style is all about. But this is not the case actually, in fact  lot of things happen behind the scene in first 500 milliseconds that you probably never think of! Let me explain it a bit.


Figure : HTTP Request-Response diagram

Whenever a request is made from a browser, along with the HTTP request browser also send HTTP headers to that web server. Some of these HTTP headers are useful for server because that carries useful information which are needed to handle that particular request. For example, with each HTTP request browser send User-Agent HTTP header to the server, seeing these HTTP header server can understand what browser has client used to make that request, what is the version client is using etc. On the other hand, along with the requested content server also returns few HTTP headers some of which carries important information like content type(how the response is going to render), how long the site will remain in cache (Cache-Control) and so on.

Some of the HTTP header returned by server is not mandatory for rendering the site content. In fact some these HTTP header (Server, X-Powered-By, X-AspNet-Version) can open security hole. Now lets consider the disaster part. What do you think what would happen if someone knows the vulnerability of a particular web server and also the version combination of that particular Asp.Net version? On such situation they can exploit those sites completely.

And for this very reason  Internet Engineering Task Force (IETF) has the following say (RFC 2068) :

Revealing the specific software version of the server may allow the server machine to become more vulnerable to attacks against software that is known to contain security holes. Implementers SHOULD make the Server header field a configurable option.

Along with the security threat that these headers are carrying with each response it also create tiny impact on the performance. A calculation shows that their inclusion simply raises  each HTTP response by around 100 bytes. This is such a small value that you might not want to bring into consideration but think again what happen if your server is receiving millions of requests concurrently? What do you think how much performance benefit you are actually giving up?


Along with the security threat that it exposes you are draining 100 bytes with each SINGLE response ! IIS Lockdown also recommends to turn these headers off.

Now that you are convinced to remove those extra HTTP header which are passing with each HTTP response, we can proceed further to see how we can remove those HTTP header, but before that lets have a glance of those header :

  • Server : Specifies web server version.
  • X-Powered-By : Indicates that the website is “powered by ASP.NET.”
  • X-AspNet-Version : Specifies the version of ASP.NET used.
Removing Server Header :

To remove this  header open up Web.Config and add the code shown below to remove the server header.

Remove Powered-By headers:

Remove X-AspNet-Version :

Summary :

From thousand feet, innocuous data that our server is transmitting is of no use to anyone, but when we dig a little deeper we find these chunks of information suddenly becomes quite useful to the evildoers. Additionally by removing those we move one step ahead in improving server performance.

Good Read:


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s