Content Security Policy

October 17, 2016
Backend Tips and Tricks Web Development

The goal of a Content Security Policy (CSP) is to prevent Cross-Site Scripting (XSS). There are a lot of ways it does this, which we’ll get into. How it works is by directing the browser to enforce the policies set forth through HTTP directives. The CSP sets a whitelist of content sources which the browser understands will be the endpoint of requests made from the page. The browser uses this whitelist to block requests made to content sources outside of the whitelist. Keep in mind that CSP is not meant to be the only defense against XSS, just another tool in the box. You should utilize other tools (like input sanitization) in addition to a CSP to prevent XSS.

How It works

When a browser makes a request to your website, the CSP should be provided with the HTML as an http-header. It’s part of the header because it’s hard to forge. The policy itself is a set of directives which instructs the browser to only render or execute content from the whitelisted sources.

What A CSP Contains

CSPs contain source directives, or, a list of sources for specific content types. Here’s the list of those:

Why It’s Needed

By default, directives are open, meaning that all sources and endpoints are allowed. It’s important to restrict the sources and endpoints because attackers can use unknown sources to perform XSS.

How To Implement

To specify sources, there are a few valid values:

Keywords are also used. When using keywords, single quotes are required.

Notes on the Above: http:// can redirect to https://, but https:// will not redirect to http://. If a port number isn’t specified, the default port will be used. If no schema is specified, the same on used to access the originating document is assumed. Allowing a domain does not include it’s subdomains, but does allow extensions (i.e. will allow to be used but not

Setting the CSP HTTP Header

The CSP’s best delivery method is through HTTP headers. Here are some examples how:

Apache config

Header set Content-Security-Policy "default-src 'self';"

# IIS Web.config
      <add name="Content-Security-Policy" value="default-src 'self;'" />
# nginx conf file
add_header Content-Security-Policy "default-src 'self';"

A lot of languages and frameworks support adding the headers programmatically, such as PHP or Node.js.

header("Content-Security-Policy", "default-src 'self'");
# node-js
request.setHeader("Content-Security-Policy", "default-src 'self'");

There is also an HTML5 tag

<meta name='Content-Security-Policy' content="default-src 'self'; script-src 'self'; ...; ...;" />

This tag goes in the <head> of the page.


When setting directives, you should always include multiple URLs in one directive (if multiple URLs are necessary). For example, if you want to allow images from AND, setting it across two directives would render whichever came first useless because the latter would override the former.


The second directive overrides the first directive.

Instead, multiple URLs should be declared in one directive, i.e.


Specific directories are not allowed, i.e. If you want to use a specific directory, just use the web root (i.e.

Other Resources

I use a lot of resources to write my articles and make sure everything is up to snuff. Here are some great articles/documentation:
Level 2 Spec on W3C SitePoint article
Mozilla Dev Article
HTML5Rocks Article

No Comments...yet

Leave a Reply

Your email address will not be published. Required fields are marked *

Previous Post

Disappearing Nav

From October 13, 2016

Disappearing navbars are found all over the web. This feature may seem like an advanced technique, but it’s actually really easy to implement.

Read This Article
Next Post

CSS: The Differences Between IDs and Classes

From October 22, 2016

Though you can achieve similar things with both, Classes and IDs are way different.

Read This Article