W3C home > Mailing lists > Public > public-webappsec@w3.org > May 2012

Re: Multiple Content-Security-Policy headers

From: Daniel Veditz <dveditz@mozilla.com>
Date: Mon, 07 May 2012 18:07:51 -0700
Message-ID: <4FA871E7.1090807@mozilla.com>
To: Adam Barth <w3c@adambarth.com>
CC: Tanvi Vyas <tanvi@mozilla.com>, public-webappsec@w3.org
On 5/7/12 3:36 PM, Adam Barth wrote:
> On Mon, May 7, 2012 at 3:29 PM, Tanvi Vyas <tanvi@mozilla.com> wrote:
>> Instead, what if we set precedence for different types of headers.  If
>> firefox see's Content-Security-Policy and X-Content-Security-Policy, it
>> ignores X-Content-Security-Policy.  If Webkit sees Content-Security-Policy
>> and X-WebKit-CSP, it ignores X-WebKit-CSP.  If either browser see's two of
>> the same headers (2 Content-Security-Policy, 2 X-Content-Security-Policy, or
>> 2 X-Webkit-CSP), set the policy to default-src 'none'.
> I'd rather not spec what implementations should do with
> vendor-prefixed headers, if we can avoid it.
> I guess I was mistaken.  I thought you and dveditz preferred that the
> user agent combined multiple policies.  If you and Dan would prefer
> that multiple Content-Security-Policy headers cause the user agent to
> enforce default-src 'none', I'm happy to update the spec to require
> that.

We definitely prefer combined policies; it seems far more useful
than default-src 'none'. Whether you apply each in series or try to
intersect them for performance reasons is an implementation detail
that should lead to the same result. We're fine having it specified
that clients should behave "as if" they were combined that way.

Whether the standard header should obsolete any experimental ones or
combine with it is a separate issue and was the main thrust of
Tanvi's mail. I've been assuming we'd obsolete the
experimental/prefixed versions but you're not wrong that it might be
useful for experimentation with future features. Probably better
than prefixed directives, anyway.

-Dan Veditz
Received on Tuesday, 8 May 2012 01:08:37 UTC

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