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

Re: [SRI] reporting (Was: [SRI] require-sri-for syntax and additional SRI/CSP interaction

From: Mike West <mkwst@google.com>
Date: Fri, 9 Sep 2016 12:45:59 +0200
Message-ID: <CAKXHy=drw40ikZnwqNSrysZk3wftPqt7CN7YU2Y=teCYgT+aCQ@mail.gmail.com>
To: Frederik Braun <fbraun@mozilla.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
On Fri, Sep 9, 2016 at 12:16 PM, Frederik Braun <fbraun@mozilla.com> wrote:

> > What would this reporting entail? I recall us being intentionally wary
> > of reporting whether or not a cross-origin endpoint returned data that
> > matched a given hash if that endpoint hadn't also opted-in via CORS
> > headers. Can I assume that you'd only report "This endpoint didn't
> > opt-in.", and not the resource's hash, in those scenarios?
> We can report integrity mismatches, but yes, I am aware that we can not
> report the hash of the offending resource. What we can report is the
> desired resource and the expected hash.
> We should also consider reporting a failed fetch due to the response not
> being cors-enabled.

As long as this doesn't give the reporting endpoint any additional ability
to determine the contents of a SRI'd resource, I'm fine with reporting
violations. That is, `<script src='https://example.com/js'
integrity='[correct hash]'></script>` and `<script src="
https://example.com/js' integrity='[incorrect hash]'></script>` should both
generate reports if `example.com` doesn't opt-in with CORS headers, and
they should probably contain the same data.

Received on Friday, 9 September 2016 10:46:49 UTC

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