W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2011

Proposal: CSP "allow-modification" directive

From: Collin Jackson <collin.jackson@sv.cmu.edu>
Date: Thu, 8 Dec 2011 12:06:04 -0800
Message-ID: <CAASTVioZF2RuO3De5qq9Dj5te9=BJ1X7BvrWJmu6ukXbR=+v=Q@mail.gmail.com>
To: public-webappsec@w3.org
Cc: Eric Chen <eric.chen@sv.cmu.edu>, Rami Shomali <rami.shomali@sv.cmu.edu>, Chinmay Garde <chinmay.garde@sv.cmu.edu>, Yolando Pereira <yolando.pereira@sv.cmu.edu>, Adam Barth <adam@adambarth.com>
One problem I see with CSP is that it encourages a one-size-fits-all policy
for an entire site, whereas in reality each page might want different
policies, and a single page might want different policies at different
times. I would like to propose a CSP "allow-modification" directive that
exposes a JavaScript API for adding new CSP directives to the current page.
I envision this would mostly be used by third-party script providers. For
example:

- Sites can delegate their CSP policy to third-party security companies on
a page-by-page basis. Right now, you can do this on a page-by-page basis
with policy-uri, but it has poor cache performance.
- Third-party ad networks (e.g. DoubleClick) could choose ad servers
dynamically to serve ad content.
- Third-party analytics providers could add and remove report-URIs without
having to get the web site change its server configuration.
- Better support for CSP in single-page web applications where more sources
of content are added over lifetime of a single page (e.g. a streaming news
feed that contains third-party images)

I don't see a security risk to setting the "allow-modification" directive
(if the attacker could run JavaScript on your site to add a new CSP
directive, they could already steal your cookies and other private data)
but it's probably a good idea to make it opt-in just in case.

Collin
Received on Thursday, 8 December 2011 20:07:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 8 December 2011 20:07:19 GMT