A CSP, short for Content Security Policy, is a layer of security you can add to your websites which will tell the browser on what sources to trust. You can configure which sources to allow in your script source, or in your img source. I can for example configure to only allow images from google.com or scripts from analytics.google.com and your own domain. And why would you want this? This is a way of mitigating XXS attacks and exploiting the browsers trust of the content received from the server. This is especially necessary when you are working with personal data, like a log-in system. The malicious scripts might run calls in the background and try to steal data. 

We want to limit the scripts that can be executed to be from trusted sources. 

Writing a CSP is simple. We need to provide the type, for which we are providing the allowed sources, and the sources themselves. We can provide full URLs, or only their domains. It supports wildcards with which you can allow all subdomains for example. Each type is separated with a semi-colon.  I'll show you an example.

This will only allow scripts from 'self', meaning the current domain, or from analytics.google.com. We also won't allow any images other than from our own domain.

This seems easly right? It is, but it can be a bit complicated once we get to a real CSP. These can get very long. It's hard to maintain those CSPs, and it's better to write some code that will write it. Let's take a loop at the CSP from mozilla.org at the time of writing. 

Good luck maintaining that. Before I will show you a way of writing CSP's in ASP.NET Core elegantly. I'll show you on how to provide it to the browser. 

There are two ways of providing the CSP to the browser. This is either by providing a meta tag with the CSP in it. Or by providing it in the response headers. My preferred way of doing it is by putting it in the response headers, this way we don't have to worry about HTML and can just write middleware that will hook into every request. Let's first look at the meta approach. 

Tip: Providing a default-src is a best practise because this is a fallback for every type if you have not provided it. This is commonly set to 'self' to only allow the website itself. Also, this is an example of only allowing images to be served over HTTPS and we won't allow any form of iframe.

The second method is by providing the Content-Security-Policy header, with the same content.

Report Only

The CSP also allows for a Report Only mode. Where it will throw errors in the console when the CSP is violated, but won't actually block it. This is useful when you just created a new CSP but are not sure if it is working. Or want your website to continue working and only log violation. You enable this by changing the key from Content-Security-Policy to Content-Security-Policy-Report-Only. This is my recommendation when you've created your CSP to see if you forgot any sources.

Reporting Violations

By providing the report-uri you can ask the browser to report violations to that url. There are many tools to log CSP violations to, and you can also write your own. My go to is Sentry, because we have this installed as our error logging and performance tracking tool. You can read more about it here. Reporting works both in the normal mode and in the report only mode.

After all this we still need to write some code to return the CSP back to the browser. We will be doing this in a configurable way, where we will be able to manage the CSP from our app settings.

So let's start. First thing we need is a model from our CSP. Looking at the examples above we can see two things. A CSP row exists of a type and a list of sources. These are both of type string, we can use a dictionary for this. We also need to be able to configure if we want to use the report only mode or not. We'll add this to the configuration as well. 

This configuration will bind to the following JSON structure. Below example is a copy from the app settings of this very website. 

Writing our middleware

The last step is to write the actual middleware. In the middleware we need to read our configuration, build the CSP, and add it to the headers. First, we need to create a class called CspMiddleware. We will inject the RequestDelegate and also IConfiguration, and bind it to our CspConfiguration.

Next, we need to create the method InvokeAsync which will run when a request is made. Here we will process our wanted behavior. I chose to first process the request, before adding the CSP header. This is to avoid unnecessary computing when the request won't be finished anyway. This can happen on any number of occasions, for example an exception occurs, or validation is not met. 

Make sure you add this to your IApplicationBuilder in your Startup or Program (depending on the .NET version you are running). Ideally, only in a non-development environment. There should be an env.IsDeveloplent() check in there by default. Add it in the opposite of this. For reference, below example.

When working with software already there you might want to exclude your CSP middleware on some occasions. For example, I work with Umbraco a lot. I don't want my CSP header added when accessing the Umbraco back-office. As a little bonus I'll show you a way to exclude the CSP from these requests. In Umbraco's case, it only operates behind the /umbraco path segment so it's simple to add. Another example is swagger, you might not want to enforce the CSP policy for your website on the swagger URL's. 

First start by adding a new line to the CSP configuration.

We've added it to the configuration. Now it's just not running the middleware when the request starts with this path segment. On the top of your middleware, below the next, add this code. 

You've learned what a CSP is, and how you should apply it in a ASP.NET Core web application. Maybe learnt something about the configuration, and the way middleware works. Hope this helps, make sure to keep your users safe from malicious attacks. It's not a lot of work to implement, and now, very easy to maintain.