CSP - Content Security Policy basics

I am fast approaching my first year working as a Software Engineer and as I contemplate the challenges I faced and my progress so far I thought I'd write about a topic I knew nothing about a year ago.
As the team grows at Brickvest, we've introduced Friday Tech talks were we each take turns and talk about topics we find interesting.
My first presentation was about Content Security Policies and I thought I'd write a blog post about it as well.

Let's start from the beginning...

1. What is CSP?

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross-Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft to site defacement to distribute malware. - MDN Web Docs

If you are a novice like myself the definition above might be a bit unclear so I will take a step back and explain what happens during an XSS attack using the diagram below.

2. Why do we need CSP?

Web security is rooted in the same-origin policy. What that means is that code from myapp.com should only have access to myapp.com's data and other applications should never be allowed access.

This is an ideal case but in reality we need to use third party apps that can potentially leave us vulnerable and attackers have found ways to break the system and exploit those vulnerabilities.

In our case we have Content-Security Policies in place for third parties like Zoho and Sentry.

The main reason we need a CSP is to protect our visitors from malicious code being executed on our website.

3. How CSP works

This is a short example explaining how CSP works:

• A user visits your website. When loading, the browser fetches the websites headers (where the CSP is specified)
• The browser parses the CSP and remembers which sources are allowed to be loaded.
• The browser now starts to load additional resources defined in your source code, like a Zoho chat, fonts, images, CSS, inline scripts, etc.
• Each resource is cross-referenced to the page’s CSP, and if a source is not specified, the resource is blocked.

4. How do I implement a CSP?

As mentioned earlier, CSP is a response header that instructs the web browser from what sources it is allowed to include and execute resources from.
All modern browser (except IE) support Content-Security-Policy HTTP headers.

The below is a very basic example of a CSP written in Python's Quart framework that uses Sentry, Zoho and Hotjar as examples. It's important to mention that each third party you want to use will have documentation mentioning what needs to be included in order to be correctly set. Here is an example from Hotjar.

Going through the above example you can notice that the CSP is split by type of resource. I'll go through the ones I included but you can find more examples and explanations here.

• self means sources that have the same protocol as the file the content policy is defined in (our own scripts). Everything else after self represents other sources that we allow content from e.g Zoho.
• default-src the default policy for loading javascript, images, CSS, fonts
• script-src defines valid sources for javascript files
• style-src defines valid sources for css files
• img-src defines valid sources for images
• connect-src provides control over fetch requests
• report_uri keep track of the violation reports. In our case we do that via Sentry.

5. What to avoid with CSP?

The unsafe-inline keyword cancels most of the security benefits that Content-Security-Policy provides as it allows the use of inline resources, such as inline elements.

Inline scripts look like this:
<script>alert()</script>
compared to:
<script src=”main.js”></script>

Allowing this gives the CSP a much weaker protection against XSS-attacks, and it’s the reason why it's prefixed by unsafe. Having to type unsafe should be a reminder that we are doing something potentially dangerous.

Unfortunately unsafe-inline is still used today (Hotjar is an example) so it's important to weigh the benefits compared with the risks before using unsafe policies.

Lastly, to end my article, here is a little tool to evaluate the Content Security Policy of your app with notes on vulnerabilities and tips on things you can improve.

Thanks you!