The Content-Security-Policy HTTP response header helps you reduce XSS risks on modern browsers by declaring what dynamic resources are allowed to load via a HTTP Header.

The Content-Security-Policy header value is made up of one or more directives (defined below), multiple directives are separated with a semicolon ;

All of the directives that end with -src support similar values known as a source list. Multiple source list values can be space separated with the exception of 'none' which should be the only value.

Domain patterns can contain both protocol and ports if you want to be specific: http://*.example.com:8080

The default-src, as the name suggests, sets the default source list for the remaining directives. If a directive isn't explicitly included in the CSP header, it will fall back to using the values in the default-src list.

All directives follow the same pattern:

• self is used to refer to the current domain.
• one or more URLs can be specified in a space-separated list.
• none indicates that nothing should be loaded for a given directive e.g. object-src 'none' indicates that no plugins—such as Flash or Java—should be loaded.

Here a few common scenarios for content security policies:

At its simplest, we could define a CSP to load resources only from the current domain as follows:

default-src 'self';

script-src 'self';

script-src 'self' www.google-analytics.com ajax.googleapis.com;

This policy allows images, scripts, AJAX, and CSS from the same origin, and does not allow any other resources to load (eg object, frame, media, etc). It is a good starting point for many sites.

default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self';

In order to prevent mixed content (resources being loaded over http, from a document loaded over https), one can use the value “https:” as a directive value.

Content-Security-Policy: default-src https:; connect-src https:; font-src https: data:; frame-src https:; 
img-src https: data:; media-src https:;  object-src https:; script-src 'unsafe-inline' 'unsafe-eval' https:; 
style-src 'unsafe-inline' https:;

The policy prevents mixed content, allows for scheme “data:” in font-src and img-src, allows for unsafe-inline and unsafe-eval for script-src, and unsafe-inline for style-src.

Mixed Content has two categories: Active and Passive. Passive content consists of “resources which cannot directly interact with or modify other resources on a page: images, fonts, audio, and video for example”, whereas active content is “content which can in some way directly manipulate the resource with which a user is interacting.

An example to block only passive mixed content:

Content-Security-Policy: img-src https: data:; font-src https: data:; media-src https:;

An example to block only active mixed content:

Content-Security-Policy: script-src https:; style-src https:; object-src https:; connect-src https:; frame-src https:; 

The established way of preventing clickjacking involves the use of the header X-Frame-Options (see: Clickjacking_Defense_Cheat_Sheet). However, CSP 2.0 has a new directive frame-ancestors.

To prevent all framing of your content use:

Content-Security-Policy: frame-ancestors 'none'

To allow for your site only, use:

Content-Security-Policy: frame-ancestors 'self'

To allow for trusted domain (my-trusty-site.com), do the following:

Content-Security-Policy: frame-ancestors my-trusty-site.com 

The frame-ancestors directive MUST be ignored when monitoring a policy, and when a contained in a policy defined via a meta element.

By default CSP disables any unsigned JavaScript code placed inline in the HTML source, such as this:

<script>var foo = "314"<script>

The inline code can be enabled by specifying its SHA256 hash in the CSP header:

Content-Security-Policy: script-src 'sha256-gPMJwWBMWDx0Cm7ZygJKZIU2vZpiYvzUQjl5Rh37hKs='

This particular script's hash can be calculated using the following command:

echo -n 'var foo = "314"' | openssl sha256 -binary | openssl base64

Some browsers (e.g. Chrome) will also display the hash of the script in JavaScript console warning when blocking an unsigned script.

The inline code can be also simply moved to a separate JavaScript file:

<script>var foo = "314"<script>

becomes:

<script src="app.js"></script>

with 'app.js' containing the 'var foo = “314”' code.

The inline code restriction also applies to inline event handlers, so that the following construct will be blocked under CSP:

<button id="button1" onclick="doSomething()">

This should be replaced by `addEventListener' calls:

document.getElementById("button1").addEventListener('click', doSomething);

Variable assignment in inline scripts. Rather than do this:

<script>var foo = "314";<script>

Leverage HTML5's custom data attributes by setting the value as follows:

<body data-foo="314”>
   ...
</body>

And access the value by doing:

var itemID = document.body.getAttribute("data-foo”);

In Chrome when a Content Security Policy Script Violation happens you get a message like this one in the Chrome Developer Tools:

Refused to load the script 'script-uri' because it violates the following Content Security Policy directive: "your CSP directive".

In Firefox you might see messages like this in the Web Developer Tools:

Content Security Policy: A violation occurred for a report-only CSP policy ("An attempt to execute inline scripts has been blocked"). The behavior was allowed, and a CSP report was sent.

Any server side programming environment should allow you to send back a custom HTTP response header. You can also use your web server to send back the header.

Add the following to your httpd.conf in your VirtualHost or in an .htaccess file:

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

In your server {} block add:

add_header Content-Security-Policy "default-src 'self';";

You can also append always to the end to ensure that nginx sends the header reguardless of response code.

You can use the HTTP Response Headers GUI in IIS Manager or add the following to your web.config:

<system.webServer>
  <httpProtocol>
    <customHeaders>
      <add name="Content-Security-Policy" value="default-src 'self';" />
    </customHeaders>
  </httpProtocol>
</system.webServer>

This is how Facebook implements CSP (line breaks added for readability).

default-src *;
script-src https://*.facebook.com http://*.facebook.com https://*.fbcdn.net http://*.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' https://*.akamaihd.net http://*.akamaihd.net *.atlassolutions.com;
style-src * 'unsafe-inline';
connect-src https://*.facebook.com http://*.facebook.com https://*.fbcdn.net http://*.fbcdn.net *.facebook.net *.spotilocal.com:* https://*.akamaihd.net wss://*.facebook.com:* ws://*.facebook.com:* http://*.akamaihd.net https://fb.scanandcleanlocal.com:* *.atlassolutions.com http://attachment.fbsbx.com https://attachment.fbsbx.com;

Note how Facebook makes use of wildcards for both subdomains, as well as port numbers in connect-src.

This is how Twitter implements CSP.

default-src https:;
connect-src https:;
font-src https: data:;
frame-src https: twitter:;
frame-ancestors https:;
img-src https: data:;
media-src https:;
object-src https:;
script-src 'unsafe-inline' 'unsafe-eval' https:;
style-src 'unsafe-inline' https:;
report-uri https://twitter.com/i/csp_report?a=NVQWGYLXFVZXO2LGOQ%3D%3D%3D%3D%3D%3D&ro=false;

Notice how the directives all contain https:, thus enforcing SSL.

Any violation of your CSP will be logged to the browser console. Whilst that may be fine when your site is under development, it's not really practical when you deploy your CSP to production.

Instead, you can use the report-uri to log all CSP violations. This directive takes a URL as its value, and makes an HTTP POST request to this URL when a CSP violation is detected. The request body contains a JSON object that is populated with details of the violation.

To illustrate this, suppose we have a CSP as follows:

Content-Security-Policy:    default-src 'self'; 
                            report-uri: https://example.com/csp/report;

This means the browser is only permitted to load resources from our own domain. However, our site uses Google Analytics, so it attempts to load JavaScript from www.google-analytics.com. This violates our CSP, so the following JSON is submitted via a HTTP POST request to our report-uri:

{
    "csp-report": {
        "blocked-uri:" "http://ajax.googleapis.com"
        "document-uri:" "http://example.com/index.html"
        "original-policy": "default-src 'self'; report-uri http://example.com/csp/report"
        "referrer:" ""
        "violated-directive": "default-src 'self'"
    }
}

If you're thinking of implementing CSP, you can take your CSP for a dry run by using the Content-Security-Policy-Report-Only HTTP header instead of Content-Security-Policy. This works just the same way as the CSP header, but it only reports on violations without actually enforcing the policy by blocking restricted resources. You can even use both headers at the same time, enforcing one policy while monitoring the effect any changes might have in the other.

https://securityheaders.io/

https://report-uri.io/home/tools

Want more info on CSP, checkout these links:

• CSP 1.0 Spec
• CSP Level 2 Spec (W3C Candidate Recommendation, 21 July 2015)
• Latest Revision
• CSP Presentations / Slides
• Mozilla Tutorial: Implementing Content Security Policy
• Mozilla MDN Docs

• https://content-security-policy.com/
• https://content-security-policy.com/browser-test/
• https://www.sitepoint.com/improving-web-security-with-the-content-security-policy/
• http://www.cspplayground.com/csp_validator

• https://www.owasp.org/index.php/Content_Security_Policy_Cheat_Sheet

• http://caniuse.com/#feat=contentsecuritypolicy2