- From: Frederik Braun <fbraun@mozilla.com>
- Date: Fri, 9 Sep 2016 09:19:07 +0200
- To: "public-webappsec@w3.org" <public-webappsec@w3.org>
Hi list, the SRI editor's draft defines an experimental CSP directive "require-sri-for" that is followed by tokens (script or style)[1] to mandate that the web page requires integrity metadata or for those loads. It was added in this pull request[2] Firefox has an experimental implementation, which lead to some good feedback. For example, we've had a bug report that suggests we should block importScript(), since there is no way to supply integrity metadata with importScript(). This inadvertedly leads to follow-up questions: 1) What should require-sri-for do for other methods that do not allow fetch-options (e.g. @import and url() in CSS)? 2) What should require-sri-for do for same-origin resources (Workers, importScripts etc. can not load cross-origin)? My thoughts so far: re 1) I don't think there's anything we can do besides blocking, if we want require-sri-for to be a security feature that websites rely on. re 2) I've been thinking about this myself and would consider allowing same-origin loads without integrity metadata. It just does not fit the use case of not having to trust a CDN. Looking forward to hearing your input! Freddy [1] I am thinking about changing the syntax, see other email. [2] https://github.com/w3c/webappsec-subresource-integrity/pull/32#issuecomment
Received on Friday, 9 September 2016 07:19:38 UTC