Why you need a Content Security Policy | Heart Internet Blog – Focusing on all aspects of the web

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.

Injecting malicious scripts into vulnerable websites

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

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.
● Do not execute JavaScript.

Defining and delivering a Content Security Policy

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.

Here’s an example of how to define a Content Security Policy around JavaScript using the script-src directive. Google’s Web Fundamentals defines script-src as “a directive that controls a set of script-related privileges for a specific page”.

So, this is an example of a directive that will prevent the execution of JavaScript in the browsers that respect the Content Security Policy:

● Content-Security-Policy: script-src ‘none’

There are two ways you can deliver this directive to the browsers of your website’s visitors:

1. Use the HTMLtag. This should be placed as early as possible in the HTML of your web pages. Here’s how you can set the script-src directive to block all JavaScript in a < meta > tag <meta http-equiv=”Content-Security-Policy” content=”script-src ‘none’;”>

2. Use a Content-Security-Policy HTTP Response Header. For example, if you use Apache, you can define the CSP in the httpd.conf, VirtualHost, or .htaccess files of your site. Just add it like this, to achieve the same result of blocking all JavaScript: Header set Content Security-Policy “script-src ‘none’;”

This second method is considered more secure and is the way W3 recommends for serving CSPs.

Examples of Content Security Policies

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:

‘none’ This will match nothing – meaning that all elements controlled by the directive will be blocked (as in our JavaScript example, above).
‘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:

1: CSP allowing only JavaScript hosted in your site:

Content-Security-Policy: script-src ‘self’

2: CSP allowing only JavaScript and images hosted on your site:

Content-Security-Policy: script-src ‘self’; img-src ‘self’;

3: CSP allowing only JavaScript hosted on your site and cdn.trustedorigin.net but images hosted everywhere:

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’;

Testing your Content Security Policies

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.

Securing your website with Heart Internet

Cross-site Scripting attacks can do serious damage to your online business. For example, the injection of unwanted malicious scripts into your site can get you blocklisted by Google . Our security partners, Sucuri, have put together a useful guide about how you can remove Google’s blocklist warnings.

But, of course, prevention is always better than cure.

That said, it’s very important to remember that a CSP is just one weapon you have in the armoury, to defend yourself against attackers. A Content Security Policy can’t defend you by itself, but only as part of your overall suite of cybersecurity measures.

If you are looking for a complete website security solution that will monitor and protect your website, look no further than Heart Internet Website Security – powered by Sucuri.

We offer daily scans, down to the server level, to ensure that any malware attempting to infect your system is stopped in its tracks. Website Security also monitors your site for symptoms such as blocklisting and issues with uptime.

Comments

Please remember that all comments are moderated and any links you paste in your comment will remain as plain text. If your comment looks like spam it will be deleted. We're looking forward to answering your questions and hearing your comments and opinions!

Got a question? Explore our Support Database. Start a live chat*.
Or log in to raise a ticket for support.
*Please note: you will need to accept cookies to see and use our live chat service