- From: Francois Marier <francois@mozilla.com>
- Date: Tue, 04 Aug 2015 19:38:22 -0700
- To: "public-webappsec@w3.org" <public-webappsec@w3.org>
On 04/08/15 04:36 PM, Brad Hill wrote: > We have two implementations shipping or nearly so, and I don't see any > indication that any implementers are interested in making further > changes beyond failing closed if CORS mode is not specified. That being > the case, any spec changes would have to be marked as AT RISK and likely > backed out in a few months anyway in order to advance the spec. It sounds like we have a rough consensus around failing closed on missing CORS. I'd like to propose the following test cases to clarify the mechanism: (a) <script src=... integrity=""> : load (b) <script src=... integrity=" "> : load (c) <script src=... integrity="sha256-uxv92iM..."> : block (d) <script src=... integrity="sha3-AKe8bj..."> : block (e) <script src=... integrity="unknowntoken"> : block All of these are missing CORS. (a) and (b) are equivalent to not using SRI (i.e. <script src=...>) and so they should load like normal script elements. (c) is a well-formed integrity attribute but it's missing CORS, so we should help the developer by failing hard. (d) and (e) are not as obvious but my reasoning for blocking them is that the developer has expressed a desire to use SRI but has forgotten the mandatory crossorigin attribute. We should treat it like (c) so that the CORS requirement is consistent with future browsers which may recognize "unknowntoken" as a valid integrity attribute or support the "sha3-" algorithm. Francois
Received on Wednesday, 5 August 2015 02:38:53 UTC