CSP Cheat Sheet

This page is a concise overview of all supported features and directives in Content Security Policy. It can be used as a quick reference guide to identify valid and invalid directives and values, contains example policies and guidance on how to use CSP effectively.


Source List - how to define sources for loading content.

Hosts | Keywords | Data | Hashes | Nonces


Directives - a list of all CSP directives.

base-uri | block-all-mixed-content | child-src | connect-src | default-src | disown-opener | font-src | form-action | frame-ancestors | frame-src | img-src | manifest-src | media-src | object-src | plugin-types | referrer | reflected-xss | report-uri | report-to | require-sri-for | sandbox | script-src | style-src | upgrade-insecure-requests | worker-src


Example policies - a look at some basic policy examples.


Building a policy - a tool to help you build a CSP.


Source List

These are the valid sources that can be specified for policy directives that accept a source list.



You can specify hosts in several forms, including:


https://*.scotthelme.co.uk This will match any subdomain on scotthelme.co.uk using HTTPS.

scotthelme.co.uk:443 This will match port 443 for scotthelme.co.uk

https://scotthelme.co.uk This will match only scotthelme.co.uk using HTTPS.

https: This will match any host using HTTPS.

http: This will match any host using HTTP.


If no port is specified the browser will default to port 80 for HTTP and port 443 for HTTPS.

If no scheme is specified then the browser will assume the same scheme that was used to access the document.

Update Sep 2015: Safari does not honour this behaviour. If no scheme is specified, the asset will not load. See tweet here. You need to specify a scheme in your CSP. You need to use https://fonts.googleapis.com instead of just fonts.googleapis.com which works fine in all other browsers.

Update Apr 2016: Safari technology preview is coming with CSP Level 2 support. The lack of a scheme on source declarations seems to be fixed.



There are several keywords available to make policy creation a little easier.


* This allows anything to be loaded for the resource type.

'none' This prevents the directive from matching any URL.

'self' This matches the scheme, origin and port of the document is was served with.

'unsafe-inline' This will allow inline resources such as scripts and styles.

'unsafe-eval' This will allow eval() and similar.

'strict-dynamic' This will allow scripts to load their dependencies without them having to be whitelisted.
Will be introduced in CSP 3

'unsafe-hashed-attributes' This will allow event handlers to whitelisted based on their hash.
Will be introduced in CSP 3



These values specify additional locations assets can be loaded from.


data: This allows data: URIs to be used, like base64 encoded images.

mediastream: This allows mediastream: URIs to be used.

blob: This allows blob: URIs to be used.

filesystem: This allows filesystem: URIs to be used.



If you want to safely inline script or style without using the 'unsafe-inline' directive you can use a
hash value of the script or style to whitelist it. If you are considering using 'unsafe-inline' you should consider using a hash or nonce instead.

'sha256-U53QO64URPPK0Fh7tsq0QACAno68LrPc5G6Avyy07xs=' This is the result of base64 encoding the binary hash of alert('Hello world!');. Any change in the script whatsoever will alter the resulting hash and the script will not be executed. This will also not whitelist externally hosted scripts, you still need to specify their origin. With this value placed in the script-src directive the browser would execute this inline script if it was placed in the page.

'sha256-RB20JxKPtBo78ZjWkZ+GR4yOncuhVeK20jxJPz4x86c=' This is the result of base64 encoding the binary hash of color: #e6400c;. Any change in the style whatsoever will alter the resulting hash and the style will not be applied. This will also not whitelist externally hosted styles, you still need to specify their origin. With this value place in the style-src directive the browser would apply this inline style if was placed in the page.



If you want to safely inline script or style without using the unsafe-inline directive you can use a nonce value to whitelist the script or style. If you are considering using 'unsafe-inline' you should consider using a hash or nonce instead.

'nonce-RANDOM_NONCE_VALUE' To use a nonce to whitelist a script on the page you would place the nonce value in the script tag like so: <script nonce="RANDOM_NONCE_VALUE">alert('Hi!');</script> The browser would now execute the script and the same method can be applied to a style tag. The nonce value should be a base64 encode of at least 128 bits of data from a cryptographically secure random number generator.

Note: Using a static nonce is not advised and is actually less secure than using the unsafe-inline directive. If the attacker utilises the nonce value, they can bypass all other restrictions in the CSP and execute any script they like. A nonce must be generated at random with each page load and inserted into the CSP and the DOM.




base-uri (source list);

This defines the URI/s that the UA can use as the document base URL.



This prevents the user agent from loading any asset using http when the page is loaded using https.


child-src (source list);

This defines the valid sources for web workers and nested browsing contexts like iframes.
falls back to default-src


connect-src (source list);

This defines valid sources for fetch, XMLHttpRequest, WebSocket and EventSource connections.
falls back to default-src


default-src (source list);

This defines valid sources for the following: child-src, connect-src, font-src, img-src, media-src, object-src, script-src and style-src.



Ensure a resource will disown its opener when navigated to.
Will be introduced in CSP 3


font-src (source list);

This defines valid sources for fonts to be loaded.
falls back to default-src


form-action (source list);

This defines valid endpoints for form actions.


frame-ancestors (source list);

This defines valid parents that may embed the page in a frame or iframe.



This directive was deprecated in CSP 2. Use child-src instead.
This directive will be undeprecated in CSP 3.
Note: Still required for WebKit which is only CSP1 compliant. See issue Troy Hunt had.
falls back to child-src as of CSP 3


img-src (source list);

This defines valid sources for images to be loaded.
falls back to default-src


manifest-src (source list);

This defines which manifest can be applied to the resource.
falls back to default-src


media-src (source list);

This defines valid sources for audio and video elements.
falls back to default-src


object-src (source list);

This defines valid sources for object, embed and applet elements.
falls back to default-src


plugin-types (type list);

This defines plugins the user agent may invoke.


referrer (value);

This controls information presented in the referrer header.


no-referrer The browser will not send the referrer header with any request.




no-referrer-when-downgrade The browser will not send the referrer header when navigating from HTTPS to HTTP, but will always send the full URL in the referrer header when navigating from HTTP to any origin.




same-origin The browser will only set the referrer header on requests to the same origin.




Warning: Navigating from HTTPS to HTTP will disclose the secure origin in the HTTP request in some cases.


origin The browser will always set the referrer header to the origin from which the request was made.




Warning: Navigating from HTTPS to HTTP will disclose the secure origin in the HTTP request.


origin-when-cross-origin The browser will send the full URL to requests to the same origin but only the origin when requests are cross-origin.




Warning: Navigating from HTTPS to HTTP will disclose the secure URL or origin in the HTTP request.


unsafe-url The browser will always send the full URL with any request to any origin.




Warning: Navigating from HTTPS to HTTP will disclose the secure URL in the HTTP request.


reflected-xss (value);

This controls any features in the user agent to protect against XSS attacks.


allow Disables any protection against reflected XSS attacks.


block Blocks loading of the resource if an XSS attack is detected.


filter Filters a detected XSS payload before execution.


report-to (token);

The token defines the reporting group that reports should be sent to.
Will be introduced in CSP 3


report-uri (uri);

This is the location that the user agent should send reports when a policy violation occurs.
Will be deprecated in CSP 3, see report-to directive


require-sri-for (script, style);

This requires that SRI integrity attributes be present for scripts and/or styles.


sandbox (values);

This applies restrictions to the actions on a page.


sandbox Enables sandbox protection with all restrictions in place. No further values need to be specified if you want all restrictions in place.


allow-forms This value allows the page to submit forms.


allow-same-origin This value allows the page to access content from the same origin.


allow-scripts This value allows the page to execute scripts.


allow-top-navigation This value allows the page to close its top-level browsing context.


allow-popups This value allows the page to open pop-ups.


allow-pointer-lock This value enables the Pointer Lock API.


script-src (source list);

This defines valid sources for JavaScript.
falls back to default-src


style-src (source list);

This defines valid sources for stylesheets.
falls back to default-src



This forces a user agent to upgrade any http request to https when the page is loaded over https.


worker-src (serialized source list);

This defines valid URLs that can be loaded as Worker, Sharedworker or ServiceWorker.
falls back to child-src


Example policies

Here are a few example policies ranging in purpose and strength.


Force all content to use HTTPS and prevents mixed content warnings. This policy can also help after a migration from HTTP to HTTPS to catch any references to HTTP assets that may still exist.

Content-Security-Policy: default-src https:; form-action https:; connect-src https: wss:; upgrade-insecure-requests

This will allow any content to be loaded from the host site, so HTTPS should be enforced with HSTS and a 301. The use of the 'https:' scheme means that assets can be loaded from any domain as long as it uses HTTPS as the scheme. The 'form-action' directive only allows forms to send data to the current domain. The upgrade-insecure-requests directive will ensure that any HTTP assets are loaded using HTTPS and the block-all-mixed-content directive it just an additional assurance that no HTTP assets will be loaded.


Only allow particular assets (script, style and image) to be loaded from external domains.

Content-Security-Policy: default-src 'self' ; script-src https://cdn.example.com; style-src https://cdn.example.com; img-src https://cdn.example.com;

This policy will allow any asset to be loaded from the host site and only allow scripts, styles and images to be loaded from cdn.example.com using HTTPS.


Read More:

Content Security Policy - An Introduction

CSP and HPKP violation reporting with report-uri.io

Combat ad-injectors with CSP and report-uri.io

Migrating from HTTP to HTTPS? Ease the pain with CSP and HSTS!

Fixing mixed content with CSP


Building a policy

The easiest way to build your own CSP is to use the policy builder tool located here: https://report-uri.io/home/generate. It simplifies the task of creating and editing your CSP by allowing the whole process to be done as a step by step process rather than editing a huge line of text.


csp generator


Dropbox did a mini-series on CSP that contains loads of useful data:

GitHub also published their CSP story:

Reshaping web defenses with strict Content Security Policy

Google - Guidance on CSP

An introduction to CSP by Mike West:

Wired are migrating to HTTPS and are using CSP to help them:

Square enabled CSP on cash.me

Setup CSP reporting with my free service:

Scan your HTTP headers:

Google CSP Evaluator

Google CSP Mitigator (Chrome Extension)

Mozilla Developer Network: CSP policy directives

Content Security Policy 1

Content Security Policy 2

Content Security Policy 3

Referrer Policy

Why is CSP Failing? Trends and Challenges in CSP Adoption

CSP Is Dead, Long Live CSP! On the Insecurity of Whitelists and the Future of Content Security Policy

A Measurement Study of the Content Security Policy on Real-World Applications

deDacota: Toward Preventing Server-Side XSS via Automatic Code and Data Separation

Short URL