Do you take the security of your website seriously?

In the same way, there are some security configurations that can be used on websites to increase security, but which are currently missing on most websites* and which we will probably look back on in a few years and wonder why we didn't use it before.

*According to a recent study by securityheaders.com, which analyzed the top 1 million websites on the web, only 5.5% of websites use CSP (content security policy).

Content Security Policy - What Is It And What Can It Prevent?

In this blog, we will look at security headers which are a kind of configuration that gives the browser instructions on what is allowed on the website. There are different types of security headers, in this blog post we will focus on the one called Content Security Policy (CSP). CSP gives you the ability to control which external sources are allowed to load different types of content on your website, thereby preventing malicious code from being injected into your web. 

Let's look at two concrete examples:

A couple of years ago, we had an editor with high privileges accidentally inserted a JavaScript into a free text field thanks to a browser plugin. It is possible to prevent an editor from being able to post this, but in this case it was allowed as the client wanted to be able to do it on the website to avoid having to go to the development team for all needs. With access to be able to execute scripts in a browser, it is possible to do quite a lot if there are no restrictions set, e.g. automatically let the user "do something" on the website (and which may not always be visible), or to change information on the page programmatically so that the visitor sees different content than the original content. In this case, the script didn't do anything dangerous, but it did demonstrate one of several ways in which scripts can accidentally enter a website.

A more common scenario is that a "mean" visitor may try to insert scripts into user-generated content, e.g. in a comment on a product or service. Of course, it's the responsibility of the development team to make sure this doesn't happen, yet it's not entirely uncommon as it requires a certain amount of expertise to prevent this. And it's not certain that it's the developer team that develops the service itself that needs to be the one who misses this. In principle, all development today is based on the use of different frameworks and modules, and these errors can also be found here, for example, the ability to add comments is common to add as a third-party service.

So what can be done to reduce the risk of this?

This is where Content Security Policy comes in. Mozilla describes the Content Security Policy (CSP for short) as an extra layer of security that helps detect and mitigate certain types of attacks, including Cross-Site Scripting (XSS) and data injection attacks. What CSP does is define what kind of resources can be loaded and used by a website, such as scripts and style sheets, but also images and files. This means that even if you for some reason are exposed to someone who has managed to get unwelcome resources onto the website, it will not necessarily be allowed to be used. It's a bit like having guards inside the entrance to the office – even if someone manages to get inside the door that requires an active code tag, the guard will check who you are and if you are really allowed to enter. The more specific the rules the guard has for who should be allowed to enter, the more likely it is that an attack can be avoided.

How to Configure Content Security Policies

Let's take a closer look at the different ways to set up CSPs. In simple terms, you can say that on each page of the website/service, you tell the browser what you are allowed to do based on a few directives, e.g. which sources (domains) are allowed to load scripts and stylesheets. These directives can be the same for the entire site, or differ from page to page. Let's say you've set up CSPs for your site and said you're allowing scripts and stylesheets from your own domain. Now, if a site tries to load a video from YouTube via a script, this video will not load. For the technically inclined, you will be able to see an error message in the developer tools saying that a video has been prevented from loading. The solution is to allow loading videos (or rather scripts when they are used to load the video) from YouTube for entire solutions, or for pages that actually have such a video.

In the same way, you need to add the corresponding configuration for other external services that the website uses in order for it to continue to work. Maybe you load scripts from Google Analytics, Google TagManager or Hotjar (analysis tool)? These need to be added. If you run Optimizely Search and Navigation, it is likely that you need to approve scripts for tracking search statistics. For a simple service that is largely controlled by developers, it is relatively easy to set up CSPs, but for a dynamic editor-driven website where a lot comes in via e.g. a tag manager*, it may require a little more time to get it right. Tt.

*Tagmanager is a tool for managing so-called tags, a kind of "code snippets" that you use to add functionality to a website. 

Inline Script Management

Scripts on a website can be handled in two different ways. Either you load a script file from a source (can be from your own domain or a third-party service) or you add a so-called script tag directly to the page. Inline scripts have the advantage that they can be generated dynamically and it can be an advantage if you need to adapt the script itself for the individual, but in most cases it is better to use separate script files.

Examples of when inlinescript is used

A common example of inline scripts is third-party systems for managing cookies where it is common for them to add both inline scripts and styles. There are also some Optimizely modules, such as Optimizely Forms, which will dynamically insert inline scripts on a page with a form.

How to handle inline scripts?

We covered how to handle script files from a source in the previous section, but what do you do if you need to have inline scripts? If you've turned on CSPs for your solution and don't manage these, then the functionality probably won't work as expected - so we need to be able to handle that.

Of course, there is a solution for this as well. The solution is to add a so-called nonce-key to the page and to the script tag that can be executed, which could be described as a kind of code key. This will be automatically generated and be relatively unique. This makes it possible to create such a key when generating the page, which can then also be added to all inline scripts on the page, and which then indicates that this script should be allowed to be executed - a bit like a one-time code. This is in contrast to the script that a user, consciously or unconsciously, has put on a page and who is then not allowed to execute because it does not have an approved code. It is possible to allow all inline scripts to be executed for a single page, which can be an option if a script is added to the page without you owning the control over how this is done – but then it also means that you remove the protection for others to execute scripts on that page. Here it is important to be pragmatic when implementing CSP's. Better to get as much protection as possible and to e.g. allow inline scripts in some cases than to do nothing at all as you thus reduce the attack vector for someone who wants to inject script on a page.

How do I know how well my website is secured?

Security on the web depends on many different factors, but if we focus on security headers, you can go to https://securityheaders.com/ and type in your domain, and you will get a quick answer to which of these are implemented on your solution. and which ones are missing.

In the next blog, we will go through penetration tests and how you can use them to increase the security of a website.

Do you want to know more about security, quality assurance or talk about the web in general? Contact us and we will be happy to answer any questions you may have, and to increase the security of your solution.