W3C home > Mailing lists > Public > public-webappsec@w3.org > September 2016

Re: [SRI] require-sri-for: missing integrity metadata? same-origin loads?

From: Mike West <mkwst@google.com>
Date: Fri, 9 Sep 2016 11:54:56 +0200
Message-ID: <CAKXHy=d7g09R3aSEXccJo-LiDDcP0LaWycxPiH5bM-tPsEsTnw@mail.gmail.com>
To: Frederik Braun <fbraun@mozilla.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
On Fri, Sep 9, 2016 at 9:19 AM, Frederik Braun <fbraun@mozilla.com> wrote:

> 1) What should require-sri-for do for other methods that do not allow
>
fetch-options (e.g. @import and url() in CSS)?



> 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.
>

Right. The conclusion we came to when adding the feature was that we should
fail these scenarios, and treat it as a good forcing function for SRI 2 to
define such mechanisms. See
https://github.com/w3c/webappsec-subresource-integrity/pull/32#issuecomment-223490845
for that discussion. :)


> 2) What should require-sri-for do for same-origin resources (Workers,
> importScripts etc. can not load cross-origin)?
>

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.
>

Hrm. It seems that "require" either means "require" or not. If you're
willing to require SRI for all scripts on your page, why would it be
helpful to make exceptions for your own origin? I think I agree with you
that there's not significant risk associated with same-origin resources,
but I'd assert that the mental model for developers is simpler to
understand if it's a binary switch.

-mike
Received on Friday, 9 September 2016 09:55:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:57 UTC