Re: Multiple Content-Security-Policy headers

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?

~Tanvi

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 18:17:39 UTC