Using Web.Config to Secure your ASP.NET Application

You can improve security of your ASP.NET application if you remove some unimportant header information from the response sent by your website.

These headers contain a number of infrastructure details about the framework that is used on your website that you do not need to publicize.


Server information header exposed

Exposing information about the server version increases the ability of attackers to exploit certain vulnerabilities. The website configuration should be changed to prevent version information being revealed in the ‘server’ header.

In your applications web.config file, add the following in the system.webserver section

<system.webserver>
  <security>
    <requestFiltering removeServerHeader="true" />
  </security>
</system.webserver>

X-Powerd-By header exposed

The  X-Powered-By header reveals information about specific technology used on the server. This information can be used to exploit vulnerabilities. The server configuration should be changed to remove this header.

In your applications web.config file, add the following in the system.web section

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

ASP.NET version header exposed

Ensuring the x-aspnet-version ASP.NET version header is not exposed makes it harder for attackers to exploit certain vulnerabilities.

In your applications web.config file, add the following in the system.webServer section

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

Content Security Policy

The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame><iframe><embed> or <object>. Sites can use this to avoid click-jacking attacks, by ensuring that their content is not embedded into other sites.

The HTTP Content-Security-Policy response header allows web site administrators to control resources the user agent is allowed to load for a given page. With a few exceptions, policies mostly involve specifying server origins and script endpoints. This helps guard against cross-site scripting attacks (XSS).

For more information, see the introductory article on Content Security Policy (CSP).

<system.webServer>
  <httpProtocol>
    <customHeaders>
      <add name="X-Frame-Options" value="DENY" />
    </customHeaders>
  </httpProtocol>
</system.webServer>