Content Security Policy

Content Security Policy

2019, May 29    

What is Content Security Policy

Content Security Policy (CSP) is an HTTP response header that gets sent from the server and it tells the browser approved sources of content that the browser can load. It is an easy and effective way to prevent Cross Site Scripting (XSS) attacks. It is supported by all common browsers (Full Table).

Why Use Content Security Policy

When a browser loads a web page there are a lot of pieces that it loads, such as images, scripts, fonts, and CSS. Using my blog as an example, all the content like pictures, posts, and the majority of scripts are local. There are a couple elements that are not hosted locally, such as some scripts and the font are loaded from Disqus for comments and Google for the font. Your browser has no way of knowing what is good to load and what is bad to load, so it just loads everything whether it is from blog.jwhite.network or malicioussite.com. By adding a CSP header, you can tell the browser that loading elements from blog.jwhite.network are fine, but anything else is bad to load.
 

Defining a Content Security Policy

There are 14 directives and policy is made up of one or more directives.

Directives Definitions
default-src Default policy that is applied to all elements if they are not set.
script-src Valid sources for javascript.
style-src Valid sources for stylesheets.
img-src Valid sources for images.
connect-src Valid sources for ajax, WebSocket or EvenSource.
font-src Valid sources for fonts.
object-src Valid sources of plugins like <object> or <embed>.
media-src Valid sources of <audio> or <video>.
sandbox Enables sandbox for request’s resources.
report-uri Tells the browser to make POST reports of policy failures.
child-src Defines valid source for web works and elements such as <frame> and <iframe>.
form-actions Valid sources for <form>.
frame-ancestors Valid sources for <frame>, <iframe>, <object>, <embed>, and <applet>.
plugin-types Defines valid MIME types for plugins invoked via <object> and <embed>.

The directives and what they define, courtesy of Content-Security-Policy.com.
Each one of those directives that ends in src supports a list of values called the source list. Multiple source list values can be used apart from ‘none’ which is used as the only value.

Source Value Description
* Wildcard. Allows for all URLs, but not data:
‘none’ Denies resources from all sources.
‘self’ Allows resources from the same origin (has to match scheme, host, and port).
data: Allows resources via the data scheme
sub.example.com Allows resources from specified domain name
*.example.com Allows resources from any subdomain under example.com
https://example.com Allows resources to be loaded only with HTTPS matching the domain.
https: Allows resources to be loaded only with HTTPS on any domain.
‘unsafe-inline’ Allows use of inline elements.
‘unsafe-eval’ Allows use of unsafe dynamic code evaluations.
‘nonce-‘ Allows script or style tag to execute if the nonce matches the header value.
‘sha256-‘ Allows script or style to execute if it matches the hash.

Using Content Security Policy

A simple CSP would be:
default-src ‘self’; img-src *; script-src https://userscripts.example.com
This policy allows anything to be loaded from itself with the default-src set to self. It allows images to be allowed from anywhere. Javascript can only come from https://userscripts.example.com. Items like fonts and stylesheets would have to load from the host itself.

Limitations & Wrap up

CSP works on the idea of whitelisting origins, which means that using inline javascript or CSS is considered unsafe. I use Jekyll for my blog and theme that I have uses scss. What this means is that the styling is all loaded inline and you can see this if you inspect this pages and look in the <head> tag. There is <style> and it contains all the CSS for my blog. While not as bad as inline javascript, it is still better to avoid. It is something that I would like to fix.

Content Security Policy is a great way to defend against XSS attacks. It works by telling your browser to whitelist origins and blocking everything else. It is easy to implement a universally supported by browsers. It is definitely something to look setting up if you do not have it already.