Security Headers - asp.net core

Introduction

One of the steps to secure your website is including appropriate security headers in your application. This helps you harden your application against very common security attacks, which are easy to prevent with security headers. There are two common methods by which we can include them in our application, and ideally your implementation should be combination of these two methods. 

In this post we will cover the most common headers, but you may decide to include more headers depending upon your security requirements.

Security Headers

The most common, and quick way to include the headers is using web.config in asp.net core application. The second way is via custom middleware.

Web.config File Example:

<configuration>

  <system.webServer>

    <httpProtocol>

      <customHeaders>

        <remove name="X-Powered-By"/>

        <add name="X-Content-Type-Options" value="nosniff"/>

        <add name="Content-Security-Policy" value="default-src 'self';

             connect-src https://www.mydomain.com/; />

      </customHeaders>

    </httpProtocol>

  </system.webServer>

</configuration>

The remaining details of the configuration file are not shown here for brevity. 

Custom Middleware Example

Only relevant code has been included for brevity, feel free to drop a comment, if you wish to see full example of  'Custom Middleware' in asp.net core. 

public async Task Invoke(HttpContext httpContext) {

    if (!httpContext.Response.Headers.ContainsKey("X-Frame-Options")) {

httpContext.Response.Headers.Add("X-Frame-Options", "DENY");

    }

    if (!httpContext.Response.Headers.ContainsKey("X-Xss-Protection")) {

httpContext.Response.Headers.Add("X-Xss-Protection", "1; mode=block");

    }

    // Included in the web.config, to include static files.

    //if (!httpContext.Response.Headers.ContainsKey("X-Content-Type-Options")) {

    //    httpContext.Response.Headers.Add("X-Content-Type-Options", "nosniff");

    //}

    if (!httpContext.Response.Headers.ContainsKey("Referrer-Policy")) {

        httpContext.Response.Headers.Add("Referrer-Policy", "no-referrer");

    }

    if (!httpContext.Response.Headers.ContainsKey("X-Permitted-Cross-Domain-Policies")) {

httpContext.Response.Headers.Add("X-Permitted-Cross-Domain-Policies", "none");

    }

    if (!httpContext.Response.Headers.ContainsKey("Permission-Policy")) {

httpContext.Response.Headers.Add("Permission-Policy", "accelerometer=(), camera=(), geolocation=(), gyroscope=(), magnetometer=(), microphone=(), payment=(), usb=()");

    }

    await _next(httpContext);

}

X-Powered-By

If your website is hosted in Internet Information Services (IIS) Server then asp.net core will return X-Powered-By header. This header we cannot remove in the Middleware so we will remove it in web.config as below. 

Web.config example:

<remove name="X-Powered-By" />

X-Content-Type-Options

When you application allow file-upload, and if the Content-Type header is blank or missing then the browser ‘sniffs’ the contents i.e. MIME-type to ascertain the file type in order to display the source in a appropriate way. 

The hacker can inject the malicious code in the file-contents or in the metadata of the file, and it will get executed when the Content-Type header is missing. X-Content-Type-Options will prevent browser from MIME-type sniffing. 

Web.config example:

<add name="X-Content-Type-Options" value="nosniff"/>

Content-Security-Policy

It contains several options to prevent multiple vulnerabilities such as Clickjacking, XSS, Frame Injection, Protocol Downgrading, etc., using this header can explicitly whitelist our resources. Here we have not cover all the combinations and options, rather one simple example. 

Web.config example:

<add name="Content-Security-Policy" value="default-src 'self'" />

X-Frame-Options

Hackers can use iframe to rick your users into clicking links injected by hackers. In majority of the modern web applications iframe are not used, so the simple solution to address this security risk is to tell the client/browser that the iframes are not allowed. The header can be easily added using middleware:

Middleware example:

context.Response.Headers.Add("X-Frame-Options", "DENY");

If in case your website does use iframe then alternatively your can change the value to SAMEORIGIN to allow your site to iframe pages.

Middleware example:

context.Response.Headers.Add("X-Frame-Options", "SAMEORIGIN");

X-Xss-Protection

As the name suggest this stops the cross-site scripting attach, when it is set the browser stops the page loading if it detect a cross-site scripting attached. 

Middleware example:

context.Response.Headers.Add("X-Xss-Protection", "1; mode=block");

Referrer-Policy

The Referrer-Policy HTTP header controls how much referrer information (sent via the Referer header) should be included with requests.

Note:  The header name "referer" is a misspelling of the word "referrer".

The Referer HTTP request header contains partial address, or an absolute address of the page, which is making the request. For a link this would be an address of the page containing the link, and when making a resource request to another domain this would be the address of the page, which is using the resource. This header helps servers identifying from where visitors are access their page, which can be used for various purposes such as analytics, caching optimization, logging etc.

When you click a link on a website, the calling URL is automatically transferred to the linked site. Unless this is necessary, you should disable it using the Referrer-Policy header:

Middleware example:

context.Response.Headers.Add("Referrer-Policy", "no-referrer");

X-Permitted-Cross-Domain-Policies

The X-Permitted-Cross-Domain-Policies header is used to permit cross-domain requests from Flash, and PDF documents. 

If you are not using Flash then disable the possibility of Flash, or PDF documents making cross-site requests using the X-Permitted-Cross-Domain-Policies header:

Middleware example:

context.Response.Headers.Add("X-Permitted-Cross-Domain-Policies", "none");

Permission-Policy

The Permissions-Policy header (formerly known as Feature-Policy) informs the browser, which platform features your website needs. 

Most web applications do not need to access the microphone, camera, geolocation, or accelerometer functions available on mobile browsers. So, it is good practice to be explicit about the features your web app needs to avoid imported scripts, or framed pages to do things you do not expect:

Middleware example:

context.Response.Headers.Add("Permissions-Policy", "accelerometer=(), camera=(), geolocation=(), gyroscope=(), magnetometer=(), microphone=(), payment=(), usb=()");

Summary

We discussed the security header which help you harden your website from simple but common attacks. 

Your feedback

Your feedback is of paramount importance to us, provide your valuable inputs; what else you would like to read about, or if you would like the author to elaborate on any specific topic from this article, or any other article on this blog.

Disclaimer

The material presented in this blog is to help educate the developers, and the author(s) & owner(s) of this blog are not responsible of any damage arising out of use of the code snippets or any other contents of this blog.