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

Re: Making it easier to deploy CSP.

From: Devdatta Akhawe <dev.akhawe@gmail.com>
Date: Sat, 13 Feb 2016 21:39:10 -0800
Message-ID: <CAPfop_15H0KB61sGdmj3RFm8ae5nN5JW2aAbGjwu9ehe9ZA3nA@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, Artur Janc <aaj@google.com>, Lukas Weichselbaum <lwe@google.com>, Michele Spagnuolo <mikispag@google.com>
> It's also a significant win in terms of deployability, as very little code
> would actually need to change. Again, anecdotally, a significant subset of
> the Google properties that folks spot-checked could use this mechanism
> without changing any JavaScript code at all, just by turning on a
> nonce-generator in their templating library.
I guess this is a subjective choice. Personally, my preference for
increasing complexity is in the order---web apps and then browsers and then
standards. Standards move almost glacially in comparison to web apps: maybe
we standardize something and we realize it didn't actually fix the problem.

If the concern is doing UA detection is a pain, I think this is another
reason to version the CSP header. Lets say that a hypothetical CSP2 header
mandates nonce support, hash support, and other improvements. IMO, this
would also reduce complexity in the web app;  'unsafe-dynamic', while
backwards compatible, seems to be increasing complexity in the app, the
browser, and the spec.

I do agree with the general concept and threat model (script elements not
inserted by parser are safer) behind this. There is also value, as Artur
pointed out, in not forcing scripts to pass around nonces. But
standardizing something for this one unique use case that could be solved
by a polyfill and UA detection seems weird. Maybe I am missing many more
use cases? I would love to learn more.

Received on Sunday, 14 February 2016 05:39:58 UTC

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