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

Re: [CSP] Dynamic CSP

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Date: Wed, 04 Feb 2015 10:28:25 -0500
To: Mike West <mkwst@google.com>, Crispin Cowan <crispin@microsoft.com>
Cc: Yoav Weiss <yoav@yoav.ws>, Deian Stefan <deian@cs.stanford.edu>, Joel Weinberger <jww@chromium.org>, Boris Chen <boris@tcell.io>, Dmitry Polyakov <dpolyakov@google.com>, "public-webappsec\@w3.org" <public-webappsec@w3.org>
Message-ID: <87mw4t7l2e.fsf@alice.fifthhorseman.net>
On Wed 2015-02-04 03:28:48 -0500, Mike West wrote:
> Consider a single-page site that loads in content via XHR or `fetch()`.
> Currently, setting a policy is only possible if it includes _every_
> resource that might be loaded by the application in any of its many states.
> That is, you'd need to whitelist all the admin resources, even though 99%
> of the users aren't ever going to touch the admin tools.

Arguably, this is just bad web application design.  Thoughtful URL
selection and generation in a web application allows users and
administrators to link to specific application contexts, facilitates
problem reports and debugging, *and* permits the use of more
narrowly-tailored page-level policies like CSP.

That is: if https://example.com/webapp is the main application, then
just put the admin interface at https://example.com/webapp/admin and
serve a distinct CSP at each location.

There may be other good arguments for dynamic CSP, but bending CSP in
potentially dangerous ways specifically to facilitate the
already-problematic "one URL for the entire webapp" model seems like a
bad tradeoff.

Received on Wednesday, 4 February 2015 15:28:43 UTC

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