W3C home > Mailing lists > Public > public-webappsec@w3.org > July 2015

SRI fail open behaviour

From: Jonathan Kingston <jonathan@jooped.com>
Date: Sat, 18 Jul 2015 11:14:01 +0000
Message-ID: <CAKrjaaV2S_VheDaR2FMk+BcN3h3KfYXUU2eOadeFsmrPJpUvAA@mail.gmail.com>
To: "public-webappsec@w3.org" <public-webappsec@w3.org>
There is a discussion going off regarding the changes discussed at the
Berlin F2F:
https://github.com/w3c/webappsec/issues/317#issuecomment-120859303

This is regarding changing the behaviour of fail-open to fail-close
whenever the following conditions are met:


   - we are loading a cross-origin resource
   - the integrity attribute is non-empty (it could be valid or invalid)
   - the crossorigin attribute is missing (i.e. it's not a CORS load)

If the request is a different origin without the correct CORS headers then
the request still must fail open.

There is also a discussion regarding should we still require the
'crossorigin' attribute or should it be implied as 'anonymous'.
There are many benefits to choosing either however I 'think' I have
persuaded myself against it again because conditional attribute defaults
based upon the origin of the page and the resource seems a little 'magical'
as @annevk stated.

I'm also unsure if there is any benefit of failing open for unrecognised
algos; it feels to me lack of control over older user agents would be a bad
thing. A custom exception here would allow users to cater for those users I
think.
Perhaps a set of options that are not related to hash-expressions might be
useful to fail close here or another attribute like:
'integrity-violations="throw-always"' (This could be a level 2 thing
perhaps)

Kind regards
Jonathan
Received on Saturday, 18 July 2015 11:14:39 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:13 UTC