There are already lots of ways to prevent XSS. We can make sure the data input by the user is never presented with markup the user might have provided, encode the data, prevent any scripts from saving to the DB, add X-XSS-Protection header. Some of the instructions are now incorporated into modern frameworks, so adding a team that contained a script in the team name didn’t cause any harm on Matchlogger.

One of the still less known ways to secure your application more is a Content-Security-Policy header. As it states in the reference guide,

The new Content-Security-Policy HTTP response header helps you reduce XSS risks on modern browsers by declaring what dynamic resources are allowed to load via a HTTP Header.

The header is now supported by all modern browsers (note: IE11 supports only deprecated X-Content-Security-Policy header). It is fairly easy to add to Spring Boot application – the only part I’ve added to the config is headers() section.

Let’s check what happens if we use a default policy on Matchlogger:

Boom. We lose all styles, images, and JS as the browser blocked loading resources because of the Content-Security-Policy header in the response. We still can add teams, though, which is good – the application seems to work without all that.

Each of the issues mentioned in the developer console shows us something else which might be important from application security perspective. While in such a small app all of those issues can be dealt with – with less or more effort – in a big application with lots of legacy code we might take a different approach. Here the best approach would be to download all the used libraries and styles into the application and instead of allowing users to put any crest URL, allow them to upload pictures (make sure the upload is secured too then!).

Content-Security-Policy allows us to both define host whitelist for script/image sources and provides some sources we could use. For example,

script-src 'self' unpkg.com 'unsafe-inline' 'unsafe-eval'

would allow us to use both JS from our origin, unpkg.com, inline scripts and eval() instruction. It still maintains a whitelist of script sources but might be useful in cases where we either explicitly want to allow inline scripts and eval(), or we know we have them in our codebase and we want to manage them from now on as a risk we would like to mitigate in future.

So, is this header helpful? From two perspectives it is.

First of all, we add a new layer of protection – the browser will compare the content it obtained from the server with its security policy, and in the case of unauthorized adding of scripts, block them.

Another good thing here is that while implementing Content-Security-Policy, we get to know our application and its potential security risks better. That’s always a good thing as we want to make sure we don’t harm our users.