CSP Is Awesome

Generate your Content Security Policy header with this online generator. (What’s CSP?)

Generate a Content-Security-Policy header

The default-src directive sets a default source list for all other directives

Deny all access

Wildcard access

URI must have the same scheme, host, and port as the protected resource's URI

Embedded data, such as a base64 encoded image

The script-src directive restricts which scripts the protected resource can execute. The directive also controls other resources, such as XSLT style sheets [XSLT], which can cause the user agent to execute script

Deny all access

Wildcard access

URI must have the same scheme, host, and port as the protected resource's URI

Embedded data, such as a base64 encoded image

Inline html entities, such as <script>alert('Hi ;)')</script>

Prevent a script from running eval()

The style-src directive restricts which styles the user applies to the protected resource.

Deny all access

Wildcard access

URI must have the same scheme, host, and port as the protected resource's URI

Embedded data, such as a base64 encoded image

Inline html entities, such as <script>alert('Hi ;)')</script>

The img-src directive restricts from where the protected resource can load images.

Deny all access

Wildcard access

URI must have the same scheme, host, and port as the protected resource's URI

Embedded data, such as a base64 encoded image

The font-src directive restricts from where the protected resource can load fonts. This applies when processing the @font-face CSS rule

Deny all access

Wildcard access

URI must have the same scheme, host, and port as the protected resource's URI

Embedded data, such as a base64 encoded image

The connect-src directive restricts which URIs the protected resource can load using script interfaces. This applies to the open() method of an XMLHttpRequest Object, the WebSocket constructor and the EventSource constructor.

Deny all access

Wildcard access

URI must have the same scheme, host, and port as the protected resource's URI

Embedded data, such as a base64 encoded image

The media-src directive restricts from where the protected resource can load video and audio. This applies to data for a video or audio clip, such as when processing the src attribute of a video, audio, source, or track elements.

Deny all access

Wildcard access

URI must have the same scheme, host, and port as the protected resource's URI

Embedded data, such as a base64 encoded image

The object-src directive restricts from where the protected resource can load plugins. This applies to the data attribute of an object element, the src attribute of an embed elements, or the code or archive attributes of an applet element. Data for any object, embed, or applet element must match the allowed object sources in order to be fetched.

Deny all access

Wildcard access

URI must have the same scheme, host, and port as the protected resource's URI

Embedded data, such as a base64 encoded image

The frame-src directive restricts from where the protected resource can embed frames.

Deny all access

Wildcard access

URI must have the same scheme, host, and port as the protected resource's URI

Embedded data, such as a base64 encoded image

Only send reports, don’t restrict access

What is Content-Security-Policy?

At its core, the Content Security Policy header allows you to define where your web pages are allowed to load content from.

A mechanism web applications can use to mitigate a broad class of content injection vulnerabilities, such as cross-site scripting (XSS)

Oh, and it’s awesome.

So why the different headers?

Since the spec is still a draft. Firefox is using X-Content-Security-Policy and Webkit (Chrome, Safari) are using X-WebKit-CSP. Once the spec is locked down they’ll move to a canonical header.

What does it look like?

Here are some examples borrowed directly from the Working Draft 1.0 document

Example 1: A server wishes to load resources only form its own origin:

Content-Security-Policy: default-src 'self'

Example 2: An auction site wishes to load images from any URI, plugin content from a list of trusted media providers (including a content distribution network), and scripts only from a server under its control hosting sanitized ECMAScript:

Content-Security-Policy: default-src 'self'; img-src *; object-src media1.example.com media2.example.com *.cdn.example.com; script-src trustedscripts.example.com

Example 3: Online banking site wishes to ensure that all of the content in its pages is loaded over TLS to prevent attackers from eavesdropping on insecure content requests:

Content-Security-Policy: default-src https: 'unsafe-inline' 'unsafe-eval'

More information

An Introduction To Content Security Policy - HTML5 Rocks

Using Content Security Policy – Mozilla

Content Security Policy 1.0, W3C Working Draft 10 July 2012

Want to know what settings your site needs?