- From: Adam Barth <w3c@adambarth.com>
- Date: Tue, 27 Mar 2012 15:06:57 -0700
- To: Daniel Veditz <dveditz@mozilla.com>
- Cc: "Hill, Brad" <bhill@paypal-inc.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Tue, Mar 27, 2012 at 1:37 PM, Daniel Veditz <dveditz@mozilla.com> wrote: > On 3/26/12 3:27 PM, Hill, Brad wrote: >> * We have heard reports that the META tag is used to delay policy >> enforcement: to pre-load some resources outside of CSP >> restrictions, then inject it into a page to "lock it down". If >> this is to be a supported use-case, I think we need to update the >> spec to make this very explicit. > > While sites might use that approach as a transitional device, I > don't think it should be an explicitly supported use-case. The only > safe way to use a <meta> policy is to put it first(-ish) in the > document to minimize the risk of content injection that could negate it. > > The HTML spec is clear that <meta "http-equiv"> has to happen in the > <head> we should be explicit about that requirement in the CSP spec > as well. Let's number the use cases for easy reference (from Brad's message): 1) Support static documents loaded by file: , data: or other non-HTTP methods 2) Get around header size restrictions for very complex policies 3) Pre-load some resources outside of CSP restrictions, then inject [the CSP policy] into a page to "lock it down". It seems like there are a few options here: A) Support only use cases (1) and (2) and require user agents to ignore <meta http-equiv> element outside the head. B) Support use case (3) via another mechanism. For example, we can add a DOM (like document.contentSecurityPolicy) that can be used to add a policy at run time. C) Suppose use cases (1), (2), and (3) using a non-http-equiv <meta> element. If this topic is controversial, we can also punt non-HTTP header policy delivery to CSP 1.1. Adam
Received on Tuesday, 27 March 2012 22:07:59 UTC