5 years ago
Stuart Larsen #article
This article is a very introductory background to Content Security Policy, it is intended for individuals who have some technical experience, but have never dug into content security policy.
Content Security Policy is not a trivial topic, unfortunately a lot of people get it wrong (Google Research).
Websites are made up of a lot of different content. There is the HTML that scaffolds the web page and gives it text. There’s the CSS that applies styles and makes it pretty. There’s the javascript that makes the web pages dynamic. There’s also images, videos, fonts and more.
Content Security Policy is a mechanism for enforcing what content (scripts,styles,fonts,images,etc) can be loaded and used by a website.
Which on the surface is a little silly. As the website owner, don’t you already get to decide what content is allowed to be used by a webpage? As a website owner you are already telling your users what content to load when you give them an HTML document.
Figure 1: A browser requesting a web page
The resulting HTML document from catbook will load the correct images, stylesheets, javascript, fonts etc. So why would I need Content Security Policy (CSP) to restrict it further?
You need Content Security Policy (CSP) to prevent cases where the web page isn’t working in the way you intended. There’s a couple of ways that this could happen, but the one that content security policy was built to solve is a prolific web vulnerability called Cross Site Scripting (XSS).
Cross Site Scripting is the unwanted/malicious execution of Javascript in a web page.
Let’s imagine that we created a website called Catbook: Facebook for Cats. It’s a social network where cats can interact with other cats through the interwebs.
Let’s imagine it had a URL such as:
https://catbook.com/profiles?userName=madCatChessy
Figure 2: The HTML content of the URL and browser rendered view
We can see that the username "madCatChessy" is taken from the URL, and then placed into the HTML by the web server, and then rendered by the browser.
So, now the fun part. What if instead we went to a web page like: https://catbook.com/profiles?userName=<script>alert(1)</script>
Figure 3: Javascript Injection into a web page (Cross Site Scripting)
Uh oh! So the webserver thought that <script>alert(1)</script>was the name of a cat. So it took the name and injected it into HTML. The HTML was then rendered by the browser and the <script>alert(1)</script>was interpreted as Javascript and not as a username.
So if you were evil you could send this URL to all your cat friends, and scare them: https://catbook.com/profiles?userName=<script>alert('Your catbook account has been deleted')</script>
While a somewhat funny prank, there’s actually a lot of truly bad stuff you could do. For example:
It’s a very serious problem, which is why all major browsers spent non-trivial time implementing Content Security Policy (along with other protective measures) to prevent these issues.
First, Content Security Policy (CSP) disables any inline javascript from running, and second it requires that you explicitly list which external origins you allow your website to download javascript from.
By only allowing certain origins to be the source of javascript(and explicitly not allowing inline javascript) we can reduce the amount of allowed executable javascript.The goal is to reduce the amount of allowed executable javascript to the point that only the javascript that can be executed is the javascript we originally intended.
Above is an example Content Security Policy. The most common origin is ‘self’ which means that on catbook.com I can load and execute javascript from <script src="https://catbook.com/app.js"/>
. You could also use cdn.catbook.com and then load javascript from <script src="https://js.catbook.com/vendor.js"/>
. What is important is the origins are trusted.
The same restrictions can be done for all types of content, but javascript is the most important.
The easiest way is to have an automated tool generate a policy for you. Csper Generator is a chrome/firefox extension that automatically generates Content Security Policy for any website.
A full guide on generating a content security policy.
I hope that content security policy makes a little bit more sense now. If you have any questions, please feel free to reach out! stuart@csper.io
How to automatically generate content security policy (CSP) headers.
Technical reference of content security policy
Guide on how to deploy content-security-policy
Csper has the tools to help you understand, deploy and manage your content security policy. Get started in minutes. Report aggregations, classification, analysis, alerting, realtime and more. Free 14 day trial.