Using CSP Header In ASP.NET Core 2.0

Problem

How to use Content-Security-Policy header in ASP.NET Core to prevent XSS attacks.

Solution

Create an empty project and update Startup to include service and middleware for MVC.

Add a _Layout page and include scripts, styles and images from local (wwwroot) and remote domains.

Run and observe the errors. When loading the page, the browser has rejected loading from remote sources.

Discussion

Content Security Policy (CSP) is an additional level of security that could help prevent Cross-Site Scripting (XSS) attacks. In these attacks, malicious scripts are executed on user’s browser since the browser doesn’t know whether the source of the script is trustworthy or not.

CSP allows developers to specify the sources (domains) that trustworthy and can serve executable scripts. This whitelisting of domains is achieved by using Content-Security-Type HTTP header, like -

Content-Security-Policy: [policy]

Here, the [policy] is made up of directives describing the type of restrictions and domains to the whitelist. It is a string defining a series of directives and sources separated by a semicolon -

[directive] <source> <…source>; [directive] <source> <…source>; …

Sources

Sources are the trusted domains; the commonly used ones are -

• *: allow any URL.
• ‘self’: allow the origin of the served page. Note that single quotes are required.
• ‘none’: no source should be allowed. Note that single quotes are required.
• Host: allow a specified internet host (by name or IP address). A wildcard (asterisk character) can be used to include all subdomains e.g. http://*.foo.com
• ‘unsafe-line’: allow inline scripts
• ‘nonce-[base64-value]’: allow inline scripts with a specific nonce (number used once). The nonce should be encrypted and unique for every HTTP request/response.

Note
Other sources could be found at Mozilla documents for developers; see Other Resources section at the end of this post.

Directives

Directives specify the resource types to put restrictions on. Commonly used ones are,

• script-src: defines valid sources of JavaScript
• style-src: defines valid sources of stylesheets
• img-src: defines valid sources of images
• connect-src: defines valid sources to which AJAX calls can be made
• font-src: defines valid sources of fonts
• object-src: defines valid sources for <object>, <embed> and <applet> elements
• media-src: defines valid sources of audio and video
• form-action: defines valid sources that can be used as a HTML <form> action.
• default-src: specifies the default policy for loading content

Note
Other directives could be found at Mozilla documents for developers, see Other Resources section at the end of this post.

Middleware

We could encapsulate the building and adding of CSP header in a reusable middleware. Below is an example to get you started. You could extend it as necessary. First, create a class to hold sources.

Create a builder. We’ll use it when setting up the middleware.

Now, we can create a middleware.

And an extension method to set it up.

We can now configure the middleware in the Startup class.

Run and observe the network traffic. The browser is allowing local and remote resources.

Other Resources

I’ve only scratched the surface of security headers and CSP. These are some of the other useful resources you could look at -

• Pluralsight course by Troy Hunt discussing security headers
• Mozilla developer documentation on HTTP headers.
• Joonas blog and sample for various security headers.

Source Code

GitHub