RE: Multiple Content-Security-Policy headers

My intuition here is to treat vendor-prefixed headers the way we proposed treating the META tag in 1.1: ignore them if an un-prefixed "Content-Security-Policy" header is present.  

Some early adopters may want to send both or will continue sending the vendor-prefixed versions to support older browsers, but I don't think this pattern is actually indicating the intent to combine policy semantics, (what the default-src 'none' behavior tries to protect against) but instead trying to communicate a single policy through multiple channels.

-Brad

> -----Original Message-----
> From: Adam Barth [mailto:w3c@adambarth.com]
> Sent: Friday, May 04, 2012 10:37 AM
> To: public-webappsec@w3.org
> Cc: Daniel Veditz
> Subject: Multiple Content-Security-Policy headers
> 
> At the face-to-face meeting, we discussed what to do when the user agent
> receives multiple Content-Security-Policy headers.  At the meeting, we
> discussed enforcing default-src 'none' as the policy in that case in order to
> fail in an obnoxious way that the developer is likely to notice.
> 
> During the test jam, and I noticed that all the tests used the following
> pattern:
> 
> Content-Security-Policy: <insert policy here>
> X-Content-Security-Policy: <insert policy here>
> X-WebKit-CSP: <insert policy here>
> 
> Do we really want to enforce default-src 'none' in this case too?
> That doesn't seem like the right thing to do.  Perhaps we ought to just
> enforce all the policies after all.
> 
> Adam

Received on Friday, 4 May 2012 18:02:45 UTC