CSP is Awesome

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

Generate a Content-Security-Policy header

Please select a CSP header type:

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

Space separated, * for wildcard subdomains, you can specify just a scheme e.g. https:

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>
Allow a script to run eval()

Space separated, * for wildcard subdomains, you can specify just a scheme e.g. https:

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>

Space separated, * for wildcard subdomains, you can specify just a scheme e.g. https:

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

Space separated, * for wildcard subdomains, you can specify just a scheme e.g. https:

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

Space separated, * for wildcard subdomains, you can specify just a scheme e.g. https:

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

Space separated, * for wildcard subdomains, you can specify just a scheme e.g. https:

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

Space separated, * for wildcard subdomains, you can specify just a scheme e.g. https:

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

Space separated, * for wildcard subdomains, you can specify just a scheme e.g. https:

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

Space separated, * for wildcard subdomains, you can specify just a scheme e.g. https:

Must use the same port and protocol as the protected resource

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

Templarbit: a service to deploy content security policy out of the box

An Introduction To Content Security Policy - HTML5 Rocks

Using Content Security Policy – Mozilla

Content Security Policy 1.0, W3C Working Draft 10 July 2012