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

On 09.09.2016 12:45, Mike West wrote:
> On Fri, Sep 9, 2016 at 12:16 PM, Frederik Braun <fbraun@mozilla.com
> <mailto: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 <http://example.com>`
> doesn't opt-in with CORS headers, and they should probably contain the
> same data.

Indeed. I was assuming that the current implementations bail-out just
after the failed CORS test, not leaving a lot of room to report
sensitive data.


> 
> -mike

Received on Friday, 9 September 2016 10:56:41 UTC