- From: Daniel Veditz <dveditz@mozilla.com>
- Date: Tue, 04 Nov 2014 23:38:27 -0800
- To: Brian Smith <brian@briansmith.org>, Brad Hill <hillbrad@gmail.com>
- CC: Chris Palmer <palmer@google.com>, Glenn Adams <glenn@skynav.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On 11/4/2014 5:12 PM, Brian Smith wrote: > to remove reflected-xss, report-uri, frame-ancestors and sandbox > directives when a policy is set via a meta tag. > > It isn't clear to me why the rules for sandbox and frame-ancestors are > different from referrer and from the defaults for other directives. Sandbox and frame-ancestors are needed before a document has started being processed to be effective. If you've already started parsing a document and maybe even run some scripts in the <head> what do you do if you encounter a meta-csp sandbox directive that says you shouldn't have run any scripts, or not run them in the same origin? Similarly if you encounter a frame-ancestor instruction that the document ought not to be loaded at all. The report-uri is banned from meta because we don't want potentially-injected CSP policies to be able to report back to an attacker's site. If report-uri could only point to the document's own domain this would be less of a worry, but that was apparently too restrictive for people trying to deploy CSP > accept that people want CSP to be simple CSP left "simple" behind long ago... > However, if we're aiming for simplicity, then the rules for > combining multiple policies should still be simplified and made as > consistent as possible--i.e. there should be as few rule-specific > combining rules as possible. I support that goal (but people will differ on what "as few as possible" means). > As for reflected-xss, I honestly don't care about it too much. But, I > feel obligated to point out that it is a specification for a W3C > standard to restrict unspecified, proprietary mechanisms. This has been removed from CSP level 2. -Dan Veditz
Received on Wednesday, 5 November 2014 07:38:55 UTC