- From: Hill, Brad <bhill@paypal-inc.com>
- Date: Fri, 4 May 2012 18:01:56 +0000
- To: Adam Barth <w3c@adambarth.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
- CC: Daniel Veditz <dveditz@mozilla.com>
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