Web Application Security using Content Security Policy

37 - Web Application Security using Content Security Policy.jpg

Web Application Security using Content Security Policy

37 - Web Application Security using Content Security Policy.jpg
Publish Date : 25-02-2024
Tags :
Author : Open-CISO

Web Application Security using Content Security Policy

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. 

Section 1: What is a CSP, and how does it work?

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';

This website is promising that it will never run JavaScript. So if the browser receives this header and then sees the page load JavaScript code, it will block the code from running and assume it is malicious. By the way, the script-src directive featured in the snippet above is the most popular CSP directive on the web. We'll see it again in section two. 

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. 

Section 2: Common CSP directives and what they do

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. 
 

script-src 

As mentioned before, this is the most popular CSP directive on the web. It tells the browser how your page should use JavaScript. This is extremely important because of a very prominent kind of attack known as XSS, which occurs when users can make arbitrary JavaScript code run in other users' browsers. To prevent this, a CSP should limit the JavaScript code that can be run, thus lowering your website's attack surface. 

There are a lot of specific ways this directive can be used, but the most important to know are the following two points: 

  1. If your page uses JavaScript, it's recommended that you aim to keep it all inline (that means hosted in separate files outside of the HTML code). The script-src directive should be set to 'self.' This means only JavaScript served from files hosted on your website are allowed to run. 
  2. If you don't use JavaScript on a page, script-src ought to be set to 'none. This blocks all scripts from running, making any XSS attacks nearly impossible. 

Adhere to these principles, in addition to tactics outside the scope of a CSP (like HTTP cookies instead of JavaScript cookies), and you'll protect user sessions against common XSS attack vectors. 
 

Frame-ancestors

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

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: 

Content-Security-Policy: upgrade-insecure-requests;

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!

Control Content rendering with a Security Policy