CSP - Content Security Policy basics
Tags: security, beginners, csp, programming
Published: 2022-01-19 21:20:04


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](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP)

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.

![XSS attack](https://raw.githubusercontent.com/ManuelaRE/images/main/Picture%201.png)


## 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](https://help.hotjar.com/hc/en-us/articles/115011640307-Content-Security-Policies) is an example from Hotjar.

{% gist https://gist.github.com/ManuelaRE/f259dcdf3f150af7a96d874934519f61 %}

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](https://content-security-policy.com/). 

- `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](https://csp-evaluator.withgoogle.com/) 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!