If you run an online business, or operate a business website of any kind, you know you need to be aware of the potential security threats to your site and, through that, to your business.
We laid out a comprehensive list of the reasons you should take cybersecurity seriously, here. And, today, we’re concentrating on one of the many techniques you can employ to protect yourself.
A Content Security Policy (CSP) is a layer of security you can add to your site to help defend against certain types of attacks. A CSP can stop modern browsers from executing malicious scripts that are injected into your site.
The World Wide Web Consortium (W3) – which was founded by web-pioneer Tim Berners-Lee – is the standards organisation for the World Wide Web. W3 describes a Content Security Policy as: “A tool which developers can use to lock down their applications in various ways, mitigating the risk of content injection vulnerabilities such as cross-site scripting, and reducing the privilege with which their applications execute.”
Cross-site Scripting (XSS) attacks consist of injecting malicious client-side scripts into your website, then using your website to spread the scripts to other users.
Client-side scripts are programs that are downloaded and run by the browser. Their functions can be as simple as flashing up an alert message in your website, to animating images, mining cryptocurrencies or showing pop-ups for embarrassing medical products.
It’s important to understand that, when attackers find a website vulnerable to XSS attacks, they have two ways of injecting malicious scripts into it:
1. Inline script: Attackers can add their code directly into your website’s HTML.
2. Load script from an external domain: Attackers load a script from multiple infected sites and modify the script when they need to.
XSS attacks happen because browsers are designed to trust all requests that come from your website, inline, or from an external source. A CSP reduces the risk of XSS attacks by allowing web developers to define directives such as:
● Execute all code coming from my domain.
● Execute all code coming from an external trusted domain and subdomains.
Every CSP is made up of two parts:
Part one is a set of directives which tell the browsers of your website’s visitors how to control specific resources in your website.
Part two tells browsers whether to enforce the CSP or not.
● Content-Security-Policy: script-src ‘none’
There are two ways you can deliver this directive to the browsers of your website’s visitors:
This second method is considered more secure and is the way W3 recommends for serving CSPs.
The complete list of directives you can use is available at W3’s website, but here are a few choice examples:
● script-src This will restrict the location from which scripts are executed, it will also block inline scripts and the eval() function.
● media-src This will restrict the location from which video, audio, and associated text track resources are loaded.
● frame-src This will restrict the location from which iFrames are loaded.
● img-src This will restrict the location from which images are loaded.
● font-src This will restrict the location from which font files are loaded.
● style-src This will restrict the location from which .css files are loaded (and also block inline styles).
Now, here are a few examples of the keywords/values you can set your directives to:
● ‘self’ This will match the current URL’s origin (the URL of your website).
● ‘https://’ This will match all resources loading over HTTPS.
Now, let’s see how these operate in practice, with some examples:
Content-Security-Policy: script-src ‘self’
Content-Security-Policy: script-src ‘self’; img-src ‘self’;
Content-Security-Policy: script-src ‘self’ cdn.trustedorigin.net; img-src *;
4: CSP blocking iFrames in your site:
Content-Security-Policy: frame-src ‘none;’
5: CSP blocking all form submissions in your site:
Content-Security-Policy form-action ‘none’;
It is important to know that every policy has a disposition, which is either “enforce” or “report“, where “enforce” applies your CSP, while the “report” one allows developers to experiment with the policy without actually enforcing it.
You can do this by defining the Content-Security-Policy-Report-Only header instead of the Content-Security-Policy header, and adding the directive report-uri (which provides real-time security reporting for your site) with a URL where you would like to see reports about CSP violations. This allows you to fix any accidental violation to your policy before enforcing it, because the Content-Security-Policy-Report-Only header is not supported inside an element.