W3C home > Mailing lists > Public > public-web-security@w3.org > January 2011

Re: XSS mitigation in browsers

From: Lucas Adamski <lucas@mozilla.com>
Date: Tue, 25 Jan 2011 16:30:59 -0800
Message-Id: <4B9F3FE8-D742-4D67-AE30-1FB71BFB284F@mozilla.com>
To: public-web-security@w3.org

On Jan 21, 2011, at 23:22, Adam Barth <w3c@adambarth.com> wrote:

> From the folks I've spoken with, this seems to depend on social or
> organizational structures.  For example, when the "ops" folks are
> separate from the "dev" folks in some sense.  In the some cases,
> (e.g., shared hosting), the "ops" folks are so separated from the
> "dev" folks that they actually have no lines of communication.  In
> other cases, (e.g., Facebook), the two are extremely well integrated.
> Adam

True, but logging in shared hosting environments is generally a well understood and solved problem.  Solutions like cPanel let web developers configure and monitor web servers without direct root access, including setting custom response headers.  In those environments web developers also function like web admins, minus the direct root access.  

As an experiment we have already provided a module for Wordpress to help automatically generate and manage CSP policies (http://wordpress.org/extend/plugins/content-security-policy/), and expect that the wider community would develop plugins for common web servers and panels to help manage and monitor CSP deployments, like they have for any other server-side technologies.  The community is very effective at bridging those tooling gaps, once a given solution has sufficiently crystalized.

The extension example you provided I think is a bit more challenging, but at the same time that's not technically web content.  So its a question of whether we want CSP to also protect applications in a fundamentally non-client/server architecture.  I'm not precluding the possibility, but it certainly hasn't been identified as priority previously.
Received on Wednesday, 26 January 2011 00:31:38 UTC

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