W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2015

Re: [CSP] Clarifications on nonces

From: Brian Smith <brian@briansmith.org>
Date: Mon, 9 Feb 2015 00:06:11 -0800
Message-ID: <CAFewVt6ETDrFnsU9QO8eL+y0T=RcNfvYprn4e15GJ-1SF_QJBw@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: Devdatta Akhawe <dev.akhawe@gmail.com>, Daniel Veditz <dveditz@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Mike West <mkwst@google.com> wrote:
> https://github.com/w3c/webappsec/commit/457db7f0596304073410f0791dfdf6329b33970f
> addresses the specific concern +1'd here. WDYT?

I think it is good to have such text discouraging the use of nonce.
But, I think it is important to explain the security issues that nonce
has so that the reader can understand *why* nonce is not secure. Feel
free to use any of the text in my previous emails describing those

> Consider a page that includes a third-party widget. Or an ad. It's quite
> likely that the page doesn't actually know what's going to be loaded via
> that widget, so constructing a CSP which would allow those things is
> difficult. Nonces, being easily transferrable, allow such embedded content
> to bring in whatever it requires.

I think that use case is one for which we should find alternative
solutions. In particular, we should be moving the web towards social
widgets and ads being confined within iframe sandbox so that embedding
an ad or widget doesn't give the ad/widget provider full control over
the page's origin like <script src=//third-party.example.com/ad.js>
does. So, I think that allowing CSP nonce to have DOM XSS
vulnerabilities in order to support the use case above is doubly

> https://lists.w3.org/Archives/Public/public-webappsec/2014Oct/0020.html is
> an example of that kind of use case, which isn't at all uncommon.

In that thread, I agree with what Florian Weber said and the message
by Sean Snider at [1].


[1] https://lists.w3.org/Archives/Public/public-webappsec/2014Oct/0099.html
Received on Monday, 9 February 2015 08:06:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:46 UTC