RE: ISSUE-4: Policy combination

I also advocate approach A. This is how we treat X-Frame-Options as well.  For example, if two headers are sent:

X-Frame-Options: sameorigin
X-Frame-Options: deny

We will allow same origin framing. But,

X-Frame-Options: deny
X-Frame-Options: sameorigin

We will deny it no matter what.

Keeping it simple like this not only reduces complexity of implementing but also makes it more straightforward for authors to implement/debug.

> -----Original Message-----
> From: Adam Barth [mailto:w3c@adambarth.com]
> Sent: Thursday, December 08, 2011 11:36 AM
> To: public-webappsec@w3.org
> Subject: ISSUE-4: Policy combination
> 
> One of our open issues is about how to deal with multiple CSP policies for a
> given resource.  At TPAC, one resolution we discussed was the
> following:
> 
> 1) If a resource has multiple HTTP headers containing CSP policies, enforce
> all of the policies.  Because CSP policies only reduce privileges (never grant
> privileges), that effectively means that an action is allowed only if it is
> allowed by all the CSP policies.
> 
> 2) If a resource has a CSP policy from an HTTP header, then we ignore any
> CSP policies that might be contained in <meta> elements.
> Otherwise, the user agent enforces all the CSP policies found in <meta>
> elements.
> 
> Another resolution (which I advocate) is the following:
> 
> A) The first CSP policy the user agent encounters for a document wins.
> 
> IMHO, approach (A) is better than approach (1+2) for two reasons.
> First, it's simpler.  CSP is already more complex that it should be.
> Adding more complexity is costly, both now in terms of implementation and
> in the future in terms of constraints.
> 
> Second, approach (1+2) constrains future evolution of CSP.  For example,
> suppose we wanted to include http://wiki.whatwg.org/wiki/Meta_referrer
> as a CSP directive.  How would we define the combination of policies
> containing referrer directives?  We'd have to define some ordering like
> "never < origin < always", but where does default fit in?
> 
> These are, in some sense, the same concern.  We can implement
> combination today, but it imposes constrains on the future that we might
> wish we didn't have later.
> 
> Adam
>

Received on Thursday, 8 December 2011 19:46:40 UTC