W3C home > Mailing lists > Public > public-webappsec@w3.org > July 2013

Re: CSP 1.1: Nonce-source and unsafe-inline

From: Garrett Robinson <grobinson@mozilla.com>
Date: Fri, 19 Jul 2013 13:48:14 -0700
Message-ID: <51E9A60E.6030808@mozilla.com>
To: public-webappsec@w3.org
On 07/17/2013 03:12 PM, Danesh Irani wrote:
> Hi all,
> 
> In the CSP 1.1 spec, a directive that has both nonce-source and
> unsafe-inline buys the user no additional protection as the browser will
> just allow all inline scripts. Previous CSP 1.1 versions of the spec
> indicated that when both directive values were specified the
> unsafe-inline would be ignored and nonce-source would be enforced
> (http://www.w3.org/TR/2012/WD-CSP11-20121213/#interaction-with-the-script-src-directive).
> 

Notice that the spec has since changed from a "script-nonce" directive
to a "nonce-source" source expression that is allowable on the
script-src and style-src directives (pending widely agreed upon spec
updates).

> From a web app deployment perspective it would be great if having a
> valid nonce-source invalidated an 'unsafe-inline', as this would allow
> having a single CSP 1.1 header which provides addition security for new
> browsers, but also works for old browsers (sort of like providing a
> backward-compatible policy and avoiding the unpleasantness of user-agent
> specific CSP). Only the CSP 1.1 spec would have to be modified to
> specify that new browsers ignore 'unsafe-inline' if a nonce-source is
> present..
> 

While that sounds like it would be convenient, I think it would be
problematic as well. Having the same policy do two different things
depending on the user's browser is confusing. We would also have to
special case it in the spec, since

    A URI matches a source list, if, and only if, the URI matches at
    least one source expression in the set of source expressions
    obtained by parsing the source list.

https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#matching

Couldn't you achieve the same result (deploying the best possibly
policy, depending on browser) easily by choosing the policy to send
based on the User Agent string, or by using the experimental meta
element support in 1.1?

> Any thoughts?
> 
> Thanks,
> Danesh
Received on Friday, 19 July 2013 20:48:41 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:02 UTC