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

Re: Multiple Content-Security-Policy headers

From: Adam Barth <w3c@adambarth.com>
Date: Tue, 8 May 2012 12:43:52 -0700
Message-ID: <CAJE5ia-_BrbTs1zAEbgSj9XweZXWURhGuR-KvXQykJX569=vmg@mail.gmail.com>
To: Tanvi Vyas <tanvi@mozilla.com>
Cc: Daniel Veditz <dveditz@mozilla.com>, public-webappsec@w3.org
On Tue, May 8, 2012 at 11:17 AM, Tanvi Vyas <tanvi@mozilla.com> wrote:
> Thinking about this a bit more, I like Adam's proposed method - take each
> source through all policies, if a source is forbidden by any one of them,
> the source is not allowed.
> This method is more future proof and doesn't require the spec to specify
> intersections per directive.  Suppose that in the future we have a directive
> "fruit" with 2 possible values - "apples" and "oranges".  Neither directive
> value is safer than the other, but one policy may have the value "apples"
> and another may have the value "oranges".  Using this method, "apples" will
> only be allowed if it passes all policies.  (The corresponding intersection
> rule for this directive would then be to only include this directive in the
> combined policy if it exists in all policies with the same value.
>  Otherwise, don't include this directive at all.)
> As far as implementation, browser vendors could decide (for performance
> reasons) to create per directive intersection rules that would yield the
> same behavior as this method.
> One question - what would happen if the two policies had different
> report-uris?  If we follow this heuristic, we wouldn't send any reports,
> correct?

Given two policies A and B, the current spec will send violations of
policy A to any report URIs in policy A and any violations of policy B
to report URIs in policy B.  We can loosen this up to make it
permissible to send violations to all the report-uris if that's easier
for you to implement.


> On 5/7/12 6:07 PM, Daniel Veditz wrote:
>> 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 19:44:54 UTC

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