Securing Your Website with a Content Security Policy

It’s no secret that website security is a complex and constantly evolving topic, with new threats and vulnerabilities emerging on a daily or even hourly basis.

One of the most common types of attack involves hackers injecting malicious code into your webpages through a security hole present somewhere within the site. For example, criminal hackers may exploit vulnerabilities in out-of-date themes or plugins, or flaws appearing in forms or commenting systems to hijack legitimate user accounts, steal financial information or execute malware on the victim site.

This is known as Cross-Site Scripting (XSS) and accounts for a significant proportion of attacks on websites today. Read more about Cross-Site Scripting.

Fortunately, it is possible to protect users against XSS and related attacks by implementing a Content Security Policy (CSP). Here’s everything you need to know… 

What is a Content Security Policy?

In simple terms, a Content Security Policy is a security standard that can be embedded within the HTTP header of a website to provide the browser with a set of instructions on what content it is allowed to run – and what it isn’t.

This policy will include a list of permissions and restrictions on resources that are loaded in the browser, including images, JavaScript and CSS, embedded content, and much more. It will also involve specifying server origins and script endpoints.

By telling the browser which content can be trusted and which should be blocked, it is possible to reduce the risk of injection attacks like Cross-Site Scripting and clickjacking.

How Does a Content Security Policy Work?

Under normal circumstances, malicious code placed into a webpage via a code injection attack would be executed by the browser when a user lands on the site. The browser is unable to differentiate between legitimate and malicious code buried in an otherwise trusted webpage, so each line of code is executed regardless.

With a CSP in place, the browser is able to differentiate between this code and will ignore all disallowed content, thereby preventing it from running. For example, a CSP can be used to prevent a malicious script loading from an attacker’s website or preventing it from sending out personal financial information.

Pretty cool, right?

While a CSP won’t prevent code injection attacks on its own, it adds an extra layer of security to your site and helps protect your users should an attack take place. It is still possible for a malicious script to be injected, but it would not be executed by the browser.

Implementing a CSP

As you can see, a carefully defined CSP is a great addition to a website and goes a long way towards safeguarding users from an attack.

A CSP is added to the HTTP site header and might look something like this:

Content-Security-Policy: default-src https://content.example.net; child-src ‘none’; object-src ‘none’

Of course, this is a simple example, and CSPs can be defined to include a wide range of whitelisted resources and permissions as necessary.

If you’re a Magento user, the good news is that Magento 2.3.5 and newer supports CSP headers and provides built-in configuration functionality. You can find out more information about this in the Magento Developer Documentation.

Want to learn more about how CSP headers can increase the security of your site? Contact us today and we’ll be happy to talk you through it.