Intent to Ship: CSP 1.1 [script/style]-[hash/nonce]

[Joel Weinberger]

Intent to Ship: CSP 1.1 [script/style]-[hash/nonce]

Contact emails

j...@chromium.org, mk...@chromium.org 

Spec

http://w3c.github.io/webappsec/specs/content-security-policy/csp-specification.dev.html#nonce-usage-for-script-elements

Summary

CSP 1.1 includes script-src and style-src directives of hashes and nonces. These allow inline scripts to execute that have been whitelisted by the server, even without unsafe-inline. This Intent to Ship will move the hash and nonce directives out from behind the experimental flag.

Link to “Intent to Implement” blink-dev discussion

There was no "Intent to Implement" as the flag already existed and this was an extension of the already implemented Content Security Policy.

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

Yes.

Compatibility Risk

If sites become heavily dependent on either hash or nonce, this could be very painful to un-ship. It would probably mean that many sites simply couldn't use Content Security Policy at all at that point (which, of course, is the motivation for implementing and shipping this in the first place). This is also not impossible. Many of the standards discussions have debated which is superior, nonce vs hash, as they serve a very similar purpose but with different costs and benefits. The consensus was to ship CSP 1.1 with both, but with the understanding that this may be revisited at a later time to see if one is dominant and perhaps remove the other. On the other hand, if developers like both, the spec might keep both.

See this W3C thread on nonce.

See this W3C thread on hash.

See this W3C thread on the debate between the two.

Most importantly, Firefox has now brought hash and nonce to default in their nightly builds, so we won't be alone on this one. See their bug.

OWP launch tracking bug?

There isn't one.

Link to entry on the feature dashboard

I believe this falls under the already existing Content Security Policy feature, but it may make sense to create a Content Security Policy 1.1 feature as well. Opinions on that welcome.

[Mike West]

Thanks, Joel! A few notes inline.

On Fri, Mar 28, 2014 at 7:27 AM, Joel Weinberger <j...@chromium.org> wrote:

Intent to Ship: CSP 1.1 [script/style]-[hash/nonce]

Contact emails

j...@chromium.org, mk...@chromium.org 

Spec

http://w3c.github.io/webappsec/specs/content-security-policy/csp-specification.dev.html#nonce-usage-for-script-elements

Summary

CSP 1.1 includes script-src and style-src directives of hashes and nonces. These allow inline scripts to execute that have been whitelisted by the server, even without unsafe-inline. This Intent to Ship will move the hash and nonce directives out from behind the experimental flag.

Yay!

As described in more detail below, I'd like to add the `frame-ancestors` directive to this intent, which more or less subsumes the funtionality of 'X-Frame-Options': http://w3c.github.io/webappsec/specs/content-security-policy/csp-specification.dev.html#frame-ancestors.

 

Link to “Intent to Implement” blink-dev discussion

There was no "Intent to Implement" as the flag already existed and this was an extension of the already implemented Content Security Policy.

We did send a similar notification to webkit-dev back in the day, however: https://lists.webkit.org/pipermail/webkit-dev/2012-May/020559.html.

 

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

Yes.

Compatibility Risk

If sites become heavily dependent on either hash or nonce, this could be very painful to un-ship. It would probably mean that many sites simply couldn't use Content Security Policy at all at that point (which, of course, is the motivation for implementing and shipping this in the first place). This is also not impossible. Many of the standards discussions have debated which is superior, nonce vs hash, as they serve a very similar purpose but with different costs and benefits. The consensus was to ship CSP 1.1 with both, but with the understanding that this may be revisited at a later time to see if one is dominant and perhaps remove the other. On the other hand, if developers like both, the spec might keep both.

See this W3C thread on nonce.

See this W3C thread on hash.

See this W3C thread on the debate between the two.

With my editor hat on, it's looking very unlikely at this point that we'll remove either. They serve different use cases, and both seem quite valuable for their respective niches. That seems to be the concensus from http://lists.w3.org/Archives/Public/public-webappsec/2014Jan/0194.html (where "concensus" means "no one disagreed with my suggestion" :) ).

Most importantly, Firefox has now brought hash and nonce to default in their nightly builds, so we won't be alone on this one. See their bug.

Firefox also has an implementation of `frame-ancestor` exposed to the web. I'd like to add that directive to this intent.

I think the rest of CSP 1.1 can easily wait until the spec hits CR. I've been expecting to take it to Last Call for the last month or so, but there's an outstanding question about paths and redirects that we need to resolve. These particular directives, however, are widely agreed-upon in the WG, are shipping in Firefox, and are critically important barriers to CSP adoption. Anecdotally, GMail isn't going to roll out CSP until these directives hit stable.

[Adam Barth]

LGTM

It's reasonable to ship hash, nonce, and frame-ancestors ahead of the other CSP 1.1 features, especially because we're acting in concert with Mozilla.

Adam

[Dimitri Glazkov]

Lgtm2

[Jochen Eisinger]

lgtm3