Manage Third-party Risk Using a Content Security Policy

A feature to prevent cross-site-scripting may make it easier to police third-party javascript.

Andy Davies and I have spoken at a number of conferences about the risks that third-party components can have on your website. In these talks we try to illustrate the fact that third-party components can have all sorts of negative consequences on your site's availability and performance. At the end of our talks we are always asked the same thing: 'what can we do about it?'.

Once you've got your third-parties under control, set up a tag management solution and identified the business value you will still have some third-parties on your site. What can we do to mitigate the risk that those critical third-parties pose? There are a number of methods to minimise the risk, such as loading the third-party scripts with an async or defer tag (after ensuring that the third-party script doesn't use document.write()!) The problem is that these third-party scripts can still make calls to fourth- and fifth- and sixth- ... parties, which can multiply the risk posed to your site. We know this through using tools such as request map which highlights how requests to these third-parties are made.

Third-party calls can become complex and hard to manage
Third-party calls can become complex and hard to manage

We don't currently have a good way to prevent these nth-party calls. Or at least not that people are using in the wild. Content-Security-Policy is a proposed HTTP Header which prevents cross-site scripting (XSS) attacks. It does this by defining whitelists of domains which can load scripts, styles images etc. from. This prevents resources being requested from malicious domains at the client-side. CSP is pretty widely supported amongst the major browsers and as it is just an HTTP header it can be set by any server-side language, any web server and any CDN. Using your CDN would allow you to define geographic-specific third-party script whitelists which would be great to prevent calls to social networks from inside China, as an example. I've built a quick example to demonstrate the concept on my site:

Console message when unexpected third-party asset is blocked
Console message when unexpected third-party asset is blocked

CSP will beacon back JSON every time a resource is blocked, it also has a report-only feature, where the request still happens at the client but it would allow you to report on unknown third-parties for further analysis. A potential secondary benefit is that you can define the protocol in the CSP - thus enforcing HTTPS on the requests and better respecting your customers' privacy.

I can see a future where tag managers will integrate with CDNs (through great APIs) and will automatically create CSPs based on the tags that are loaded for each page and geography. Wouldn't that be nice! Until then, though, it will take some manual intervention to get CSPs up-and-running.

Would you use this to restrict the third-parties on your site or is CSP too extreme for your needs? Please let me know if you try it out in the wild!