Intent to ship: Content Security Policy Level 2

Skip to first unread message

Mike West

Sep 25, 2014, 4:07:36 AM9/25/14
to blink-dev

Contact emails,



Content Security Policy Level 2 is, as you'd expect, an evolution of the Content Security Policy specification. Level 2 makes two breaking changes, and adds support for a number of new directives and capabilities which are summarized in the "Changes from 1.0" section of the spec:

The WG has just completed a Last Call on the current Working Draft (; I'd like to begin moving pieces out from behind the flag while we go through the formalisms of proposing a transition to Candidate Recommendation.

Link to “Intent to Implement” blink-dev discussion was the announcement on webkit-dev, way back when. Joel shipped parts of CSP2 in

Is this feature supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?



We generate console messages for most violations, and the headers are easily inspectable via the network tab.

Compatibility Risk

There are 4 breaking changes in CSP2, summarized in One we need to make for security reasons (ignoring path components after a redirect), and the rest for clarity going forward:

* Workers are moving from 'script-src' to 'child-src'. This should have an extremely small impact, as evidenced by the UMA metric:

* Workers will have their own policy, rather than inheriting a policy from their creating document. This is necessary to support Service Workers (but isn't yet implemented).

* Redirects are blocked by default, governed by 'unsafe-redirect'.

The last of these might be disruptive: I intend to add metrics for the 'unsafe-redirect' change, and I'll come back to the list with numbers before shipping this change.

Other vendors are generally supportive:

* Firefox will be making these changes as well.

* IE does not yet implement CSP, but is working on implementing CSP2 in a future release:

* Safari hasn't substantially touched their CSP implementation since we forked, nor has Apple participated in the WG. If that continues, then I'll try to submit some patches.

OWP launch tracking bug?

Link to entry on the feature dashboard


Jochen Eisinger

Sep 25, 2014, 4:29:50 AM9/25/14
to Mike West, blink-dev
Can you specify which pieces you'd like to ship first?


Mike West

Sep 25, 2014, 4:46:56 AM9/25/14
to Jochen Eisinger, blink-dev
On Thu, Sep 25, 2014 at 10:29 AM, Jochen Eisinger <> wrote:
Can you specify which pieces you'd like to ship first?


* Step 0: We're already shipping hashes and nonces.

* Step 1: Move the following pieces out from behind the flag:
  * 'base-uri' controls the protected resource’s ability to specify the document base URL.
  * 'child-src' deprecates 'frame-src', controlling the protected resource’s ability to embed frames, and to load Workers.
  * 'form-action' controls the protected resource’s ability to submit forms.
  * 'frame-ancestors' controls the protected resource’s ability be embedded in other documents. It is meant to supplant the X-Frame-Options HTTP request header.
  * 'plugin-types' controls the protected resource’s ability to load specific types of plugins.
  * 'referrer' controls the protected resource’s referrer policy.
  * 'reflected-xss' controls the user agent’s built-in heuristics to actively protect against XSS. It is meant to supplant the X-XSS-Protection HTTP request header.
  * The 'SecurityPolicyViolationEvent' DOM event, which fires upon violation.
  * The 'effectiveDirective', 'statusCode', 'sourceFile', 'lineNumber', and 'columnNumber' violation report fields.

* Step 2:
  * Implement and ship a 'CSP' request header, as outlined in
  * Implement and ship separate policies for Workers (I've started on this by making it possible to create CSP objects outside of Documents, but I need to wire them up to workers' construction).
  * Implement and ship changes to path processing after redirects (as described in
  * Implement and measure the impact of blocking redirects by default ('unsafe-redirect').
* Step 3: 
  * Bring the numbers from the 'unsafe-redirect' measurement back to blink-dev as a separate Intent to Ship.

Step 1 could happen today. Step 2 will take a little longer, as I'm working on the implementations. Let's say early Q4. Step 3 would be whenever the relevant metrics get to stable. Let's say Q1.


Jochen Eisinger

Sep 25, 2014, 4:49:43 AM9/25/14
to Mike West, blink-dev
does the referrer policy already support the FPWD policies, or just the old ones from the whatwg wiki?

Mike West

Sep 25, 2014, 4:52:51 AM9/25/14
to Jochen Eisinger, blink-dev
It will certainly be using the new keywords (while continuing to support the old keywords) before shipping. I don't recall off the top of my head if we've already made that change or not.

That said, our referrer policy implementation doesn't yet support the new 'origin-when-cross-origin' policy; that's probably best dealt with as a separate intent.


Mike West <>
Google+:, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Jochen Eisinger

Sep 25, 2014, 4:57:12 AM9/25/14
to Mike West, blink-dev
ok, shipping step1 lgtm


Sep 25, 2014, 10:36:26 PM9/25/14
to Jochen Eisinger, Mike West, blink-dev

Software Engineer, Google

Alex Russell

Sep 26, 2014, 2:29:39 AM9/26/14
I don't have a vote here, but you have whatever support I can lend. Make it so!

Adam Barth

Sep 30, 2014, 1:21:02 AM9/30/14
to Jochen Eisinger, Mike West, blink-dev
lgtm (although I might be a bit biased)
Reply all
Reply to author
0 new messages