Maybe you're a non-technical manager who's been told that a web app or website needs something called a CSP, and you have no idea where you should even start working. Or perhaps you are technical but don't have a background in web security and want a basic idea of what a Content Security Policy is and what it does to protect a web application. Lucky for you, we've prepared this practical guide to understanding Content Security Policies. But, again, you don't need to be an expert in web security - we've written everything so that anyone can understand, even if you have no background in security or web application development.
So please sit back and relax as we walk you step-by-step through the purpose and features of this powerful tool for making your web app or website safer. First, we'll start with a broad overview of how a CSP works. Then in section two, we'll go through specific CSP 'directives' or commands and what they do. That way, you'll be able to participate in meetings and know enough to delegate CSP-related tasks to your team members effectively.
A quick caveat before we dive into the techie part: this article is not intended to be a complete reference for implementing a CSP from top to bottom. For that, we recommend consulting Mozilla's Documentation on the topic. It's an excellent resource for engineers hoping to master the ins and outs of CSP design. But for those who want to get this gist and quickly attain competence.
A CSP is a series of commands, called 'directives,' sent to the browser. They tell the browser, "Hey, this app shouldn't ever run this kind of code. So if you find something like this, it means something fishy is going on". When the browser notices behavior occurring that's forbidden in the CSP, it kills the code. That way, malicious code that depends on features banned by the CSP won't run, and your users will be protected from specific attacks. To demonstrate, consider the following CSP header (CSP's are given to the browser by the web server, so they are delivered via something called HTTP headers)
Content-Security-Policy: script-src 'none';
To illustrate that the CSP runs in the browser, and thus on the user's computer, consider the logical flow of data in the following chart:
Now that you've hopefully acquired a firmer grasp of what a CSP is, where it runs, and thus, what it's capable of, let's move on to the nitty-gritty of what it's most commonly used for.
As we alluded to earlier, a CSP is divided into different commands called 'directives,' which do other things. This section will give an overview of some of the most common CSP directives. This should leave you with a solid enough grasp that you'll have no trouble facing a meeting with a security team discussing issues related to a CSP, all while feeling at home with the topics discussed.
But if you want to dive deeper into more obscure directives and features, we recommend that you peruse the Full List of CSP Directives for further reading.
There are a lot of specific ways this directive can be used, but the most important to know are the following two points:
Other sites can load your web page in a "frame" inside their area. They can make the frame invisible and put other content on top of it, but when users click the content, they click things on your site. For example, they might trick your users into deleting their accounts or transferring money. This classic attack is called clickjacking, and to prevent it, you set your CSP to tell web browsers, "Hey, if someone tries to load this page inside of a frame, it's not legit, and the user is likely being attacked." Its usage is simple, to prevent a page from being loaded in a frame, you use the directive like so: >
Content-Security-Policy: frame-ancestors 'none';
You can also allow specific, allowed domains to load a page in a frame, in case that's necessary. You just put the URL right there in the directive:
Content-Security-Policy: frame-ancestors https://url1.com https://url2.com;
HSTS stood for HTTP Strict Transport Security and was created by Alphabet, Inc (formerly known as Google) to prevent a certain kind of Man in the Middle attack. The specific details of this attack are too intricate to explain here (but if you're curious, you can learn more by checking out this famous talk by legendary security expert Moxie Marlinspike, who invented the attacks that led to the creation of HSTS and is now renowned for founding the startup Signal). Of course, you implement this using a few headers, not just your CSP. But the CSP part of it looks like this:
For a complete primer on implementing HSTS Compliance
Congratulations, you did it! CSP's are simple, but the distinct parts can be a lot to take in first. If you're intimidated, remember that unless you're implementing a CSP yourself from scratch, then 99% of the time, you'll only need to know the most common directives and have a general idea of what purpose they serve. Armed with this, you'll be more than ready for any meeting or technical discussion with your team. Good luck!