Managing the 'Content Security Policy' of your site

test

Introduction

The 'Content Security Policy' response header is used to enhance a website's security. It allows control of how resources are loaded, whitelisting trusted domains.

Any security audit will highlight this as a key recommendation.

Content-Security-Policy: default-src 'self' ; script-src https://www.google-analytics.com https://ssl.google-analytics.com; img-src https://www.google-analytics.com; connect-src https://www.google-analytics.com;

Why

Content Security Policy is an extra layer of security that protects against certain types of attack vectors (XSS, Clickjacking). Anything you can do to protect the end-user is beneficial.

It is common practice these days for developers to draw in 3rd party packages to deliver a feature and these packages will also draw in other packages. This means that malicious code can get drawn into your solution without your knowledge.

How

It is possible to be very granular when configuring the security policy. This gives you a high level of control of what can be loaded and where data can be sent.

Although the Content Security Policy can be added as a meta tag, it is typically delivered in a response header. Additionally, it is also possible to enable specific inline scripts by adding a nonce value.

Testing your policy

Changes to the policy can inadvertently disable features on your site. YouTube videos can fail to load, analytics may stop sending data, and JavaScript components can also fail. To help mitigate this, you should either make any changes as 'report only' and monitor the output, or configure the policy to report issues. This means that any problems are either reported within the browser console or sent to a third-party reporting service.

Challenges

You have deployed your policy, it's been tested and signed off, but then things start to fail. Unfortunately, things do change; a dependency can update the endpoints they use, or more typically, a new tool is added via Google Tag Manager.

Managing the content security policy can be challenging. A common approach is to create a Url Rewrite outbound rule. This means that when the policy needs to change, you have to update your source code and redeploy your site, which is not very efficient.

Is there an easier way?

Read my next post, where I will introduce the new Episerver / Optimizely module that simplifies the management of the Content Security Policy.

Next Post: Introducing Jhoose Security - A module to manage your Content Security Policy