I’ve talked about how to how to remove HTTP Headers that you don’t need from IIS – but there are some that you probably will want. This particular post is about the Content Security Policy (CSP).

I’m not going to describe what one is. @Scott_Helme has already described what a Content Security Policy is far better than I can. Rather, I’m going to describe how to figure out what your policy should be…

I mean, imagine this – you’ve a large website containing hundreds or thousands of pages, built up over a number of years, by a number of developers or a number of companies. You simply don’t know how it all works – what scripts it uses, where they’re all loaded from, where the CSS comes from, if IFRAMES are used, and so on. You might be using plugged-in scripts that load other resources of their own that you don’t know about. If someone turned around and said that those should all now be whitelisted – what a CSP effectively is – well, that might cause some small amount of panic.

Well, it turns out that when the CSP standard was was specified, someone thought of this – and we got the Content-Security-Policy-Report-Only header. This header, if set, will cause the browser to evaluate a policy, but not enforce it. You can see errors reported in things like Chrome’s developer window:

Nice. But I really don’t want to have to trawl through my site looking for violates – there could be thousands of pages. Well, they thought of that too. One of the settings in the CSP is the report-uri setting. This tells the browser to send a report of violations to a suitable service – like report-uri.io. This is another Scott Helme site, and I love it. I mean, it isn’t a revolutionary idea – it’s just fantastically simple and easy to use:

Look, a report of my violations! With a count! And a time-window! Or we can have a top 10 report of violating pages, and things that are violating:

Brilliant! So I can prioritise what I need to fix. I can see what unexpected stuff would break. This makes it possible to formulate a working policy.

Therefore, my process would be:

1. Set up a fairly tight policy in Content-Security-Policy-Report-Only mode.
2. Let it run for a while with my site.
3. Review the violations and, where necessary, alter the policy.
4. Repeat 2-3 until I’m happy that I’m not getting any incorrect violations being logged.
5. Change the content security policy from Content-Security-Policy-Report-Only to Content-Security-Policy
6. Wait to see if anything breaks or anyone panics.

Note that the violations need to be reviewed and assessed whether they should be allowed by the CSP. Don’t just add them. As Scott Helme says:

The authenticity of incoming reports can never be assured and their contents could well be maliciously crafted by an attacker themselves. Any of the URI values in the report may link to malicious content, and visiting a unique URI could divulge information about the admin that received the report.

So check what you’re allowing – it’s mandatory.

Oh, and what supports Content Security Policy v1.0? Well, this page should help.