- From: Adam Barth <w3c@adambarth.com>
- Date: Sat, 22 Jun 2013 22:03:13 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Boris Zbarsky <bzbarsky@mit.edu>, Gordon Hemsley <me@gphemsley.org>, WebAppSec WG <public-webappsec@w3.org>
On Thu, Jun 20, 2013 at 12:27 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > Context: http://wiki.whatwg.org/wiki/Contexts (hah) > > On Fri, Jun 7, 2013 at 1:35 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote: >> We should probably add at least workers, XMLHttpRequest, SVG resource >> documents, document.load, XSLT. Probably eventually the components import >> stuff. > > It seems XMLHttpRequest is connect-src. Workers are covered by > script-src. HTML component imports are covered by script-src (for > now). > > Not clear about SVG, It depends on how you load SVG. If you use <img src="foo.svg">, then it's covered by the img-src directive. If you use <iframe src="foo.svg">, then it's frame-src. If you use <object data="foo.svg">, then it's object-src. More generally, CSP cares about the API that generated the fetch, not about the type of resource returned by the server. > document.load, That's a script-based API, so it's in the connect-src bucket. > and XSLT. Adam? You might think that XSLT is controlled by style-src because it's styling information, but we've actually put it into the script-src bucket because it's just as powerful as script. You can see some discussion of this topic if you search for XSLT in https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html. >> Does EventSource do a fetch internally? > > Yes. > >> I'm not sure whether any UAs fetch DTDs in practice, but if so they should >> be added too. > > I think we should treat that as a bug :-) I don't think there's anything in CSP that controls DTD fetches. Do any user agents actually fetch DTDs? >> <object> might need to be a separate context from "nested browsing" and >> "plugin", possibly. It really depends on how the spec for it reads. > > It seems object-src is defined as being applicable to any kind of > fetching <object> / <embed> / <applet> might do. Calling it a plugin > context might be somewhat misleading, but I don't have a better idea. Yeah, that was a topic of discussion on public-webappsec for a while, but we settled on the "syntax-based" approach in the spec. That means <object> is controlled by object-src regardless of whether it ends up creating a nested browsing context or a plugin. Adam
Received on Sunday, 23 June 2013 05:04:12 UTC