On Sun, Oct 30, 2016 at 3:18 AM, Christoph Kerschbaumer < ckerschbaumer@mozilla.com> wrote: > I agree that consistency is very important, but I am afraid current CSP > spec is already *not* consistent in that case. E.g. we allow unsafe-eval as > well as unsafe-inline to appear in script-src as well as in default-src, > but we only allow nonce to appear within script-src but not in default-src, > right? > I don't see that restriction in either CSP2 or CSP3, though both specs are complex and maybe I missed a section that modifies the sections I did find. CSP2 says "The term allowed script sources refers to the result of parsing the script-src directive’s value as a source list <https://w3c.github.io/webappsec-csp/2/#parse-a-source-list> if the policy contains an explicit script-src, or otherwise to the default sources <https://w3c.github.io/webappsec-csp/2/#default-sources>." Didn't see anything in the section on nonces or default-src that made an exception. CSP3 defines nonces in the generic "source list" section, and the script section says Inline script <https://html.spec.whatwg.org/multipage/scripting.html#script> blocks MUST pass through §4.2.3 Should element’s inline type behavior be blocked by Content Security Policy? <https://w3c.github.io/webappsec-csp/#should-block-inline>. Their behavior will be blocked unless every policy allows inline script, either implicitly by not specifying a script-src (or default-src) directive, or explicitly, by specifying "unsafe-inline", a nonce-source <https://w3c.github.io/webappsec-csp/#grammardef-nonce-source> or a hash-source <https://w3c.github.io/webappsec-csp/#grammardef-hash-source> that matches the inline block. ... which seems pretty clear that default-src supports the same directives. 'strict-dynamic' ought to work the same way. - Dan Veditz
Received on Monday, 31 October 2016 21:11:25 UTC