Prevent XSS Attacks with a Nonce in the Content Security Policy

It is important to think about what sources of JavaScript you will allow on your website. JavaScript is code that will be executed by the user's browser. It can be used as a vehicle for a Cross Site Scripting (XSS) attack if the right precautions are not put into place. Controlling the sources of JavaScript executed as visitors come to your website is key.

As mentioned in a previous post on our blog, Content Security Policy has a script-src directive that defines valid sources of JavaScript for a given site. The script-src directive can be used to specify specific origin hosts and URI schemes that JavaScript can be loaded from in the markup. It also can be used to lock down certain types of JavaScript that are more likely to be used as an attack vector, such as inline JavaScript and dynamically evaluated JavaScript.

JavaScript is the foundation of the modern web. It is a valuable tool in creating rich experiences that visitors engage with. It is not feasible to configure the script-src directive to disable JavaScript entirely, so we must configure it to be as secure as possible, while still allowing for this code to be delivered in a secure way.

One tool that we recommend using to solve this problem is to use a Content Security Policy with a nonce in the script-src directive. A nonce is a randomized value that is only used one time. Adding a nonce to the script-src will tell the browser that is serving your website to only allow execution of JavaScript with that specific nonce value set on the script tag in the markup as well. Scripts in the markup without that nonce set will not execute.

An example of a script-src with a nonce set looks as follows:

script-src 'nonce-KRsfYescGho0GHFPPGAncXaqaV0DG5oJvUAmTOuUFLM='

A corresponding script tag in the markup would look like this:

<script nonce="KRsfYescGho0GHFPPGAncXaqaV0DG5oJvUAmTOuUFLM=" src="/path/to/javascriptfile.js"/>

The key to a successful usage of a nonce in the script-src is that the nonce value is unique for every visit to your site. There must be functionality in place that generates a unique value every page load. Furthermore, this functionality must dynamically alter the script-src directive and all scripts in the markup to have this nonce value as well.

This nonce uniqueness requirement makes the solution well suited for the Digital Experience Platforms we help our clients utilize. This is not the type of functionality that can be set in static markup once and forgotten about. There must be technology in place to ensure that the nonce is applied to both the script tags in the functionality in use today, as well as future functionality that does not exist yet.

We have an accelerator that we have developed here at Layer One for our clients on Sitecore that helps put this functionality in place rapidly. It also solves other problems around the management of the Content Security Policy directives. I will be talking about that more in a blog post coming this Friday - stay tuned!