Bil Corry wrote: > > I personally see value there for the website, but if 99.9% of websites > will never do anything with the header, then it probably isn't > worthwhile (or it may take version 2 before the need is evident). The > big challenge here is making sure the CSP announcement header can not > be spoofed via XHR, so to that end, I'd recommend prefixing the header > name with "Sec-" such as "Sec-Content-Security-Policy" -- the latest > draft of XHR2 specifies that any header beginning with "Sec-" is not > allowed to be overwritten with setRequestHeader(): > > http://www.w3.org/TR/XMLHttpRequest2/#setrequestheader > > Of course, XHR2 would have to be implemented in the browsers first in > order to take advantage of the requirement.
My 2c is that if we do this we should do versioning from the get go, otherwise servers will have a hard time telling CSP v1.0 from CSP unsupported clients in the future. On one hand this may waste some bandwidth now, but then again if it saves the server from sending CSP responses to clients that don't support it, it may actually save bandwidth and simplify server logic (since servers will be able to determine conclusively that CSP is supported, rather than guessing). > > I don't have a specific use case, I'm thinking more of the edge cases > where content is allowed from a domain that allows a multitude of > third-party content. Maybe this is something to explore for v2 if > warranted. > I think part of the challenge is that CSP governs a number of different operations, some of which may be meaningful to restrict to a specific path but others may not be (i.e. scripting vs asset loading). If we had a few specific examples that would help us get our brains around whether or not enforcing restrictions on a per-path basis would actually be a contract that is enforcable. For (a contrived) example, say mashup.com hosts a number of different widgets, but myapp.com wants to restrict loading of iframes from only mashup.com/good. If the user happens to have another app from mashup.com/bad loaded in another window/tab, then in theory content from mashup.com/bad could script directly into the iframe contain mashup.com/good within myapp.com, bypassing the loading restriction. That is probably not the best example, but the root of this problem is that scripting permissions are really still only enforceable on a per fully-qualified domain name basis, regardless of any loading restrictions. > >>> (3) Currently the spec focuses on the "host items" -- has any thought >>> be given to allowing CSP to extend to sites being referenced by "host >>> items"? That is, allowing a site to specify that it can't be embedded >>> on another site via frame or object, etc? I imagine it would be >>> similar to the Access Control for XS-XHR[2]. >> I would agree with Gerv, that this feels a bit out of scope for this >> particular proposal. > > Then maybe something to consider down the road. It would be useful to > prevent hot linking and clickjacking > . I think the primary reason this seems out of scope is that CSP is a mechanism for servers to govern their own content, rather than specifying policies for 3rd party content. The latter seems more like the domain of Access Control. Access Control AFAIK is not intended just for XHR2, so I could image it being extended to govern opt-out of cross-domain content loading, as well as to opt-in. Thank you for your feedback btw, it is much appreciated. Lucas. > > - Bil > _______________________________________________ > dev-security mailing list > dev-security@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
