I think it makes sense to have reporting. If the integrity check fails because the asset has changed then it could be a serious problem for the site in question.

If a website is using both CSP with "require-sri-for" directive and SRI and there is a hash validation error, it would be very useful to be able to levarage the CSP report-uri/report-to directive to send violation reports. Protecting end users by blocking if there are SRI errors is priority #1 however visibility into SRI failures is a close #2 for website owners to be able to identify large issues such as Magecart JS skimmer injections.

Question - other browser feature such as X-XSS-Protection has been updated to piggy-back on the CSP reporting code by adding in the report option - https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection#Syntax. Could SRI do similar with adding in a report flag along with the integrity and crossorigin flags?

Who do we need to include to determine interest in this?

@mikewest what do you think?

@mikewest what do you think?

I think no one is actively working on SRI, and that it would be nice if someone was. :)

Adding a reporting mechanism to SRI based on the reporting API sounds fine to me. It's not immediately clear how you'd specify which reporting group SRI would fall into, or what data you'd like to include in the report, but I'm sure clever folks like the SRI spec's editors can figure something out that could make sense.

are you saying chrome will implement it if spec'ed? :D

I'm saying that it sounds like a perfectly idea with some non-trivial details that I would love for someone else to work out because I don't have the time to spend on it. Once those details are worked out, we'd move into the "patches welcome!" stage of development. :)

Given finite resources, this doesn't seem like something that would be at the top of our list of things to implement, but it doesn't sound too hard to do once we figure out how we'd want to do it. How valuable is it? Where would Dropbox stack-rank it in terms of the things you'd like to see browsers spend time on?

Ok, @ScottHelme, where would ReportURI rank this in terms of the things you'd like to see browsers working on?

We're actually working on a way to do SRI reporting ourselves but it's not ideal given it'd have to be an extension of Report URI JS and there's no easy or clean way to do it, it's kind of messy (which is why we don't have it as a feature yet). It also means deploying code, which, eugh...

If this was natively supported by the browser and reports were dispatched via the Reporting API, we'd absolutely support this. In terms of the fields in the report I'm sure others can provide insight but it'd be nice to have a document-uri, blocked-uri, expected-hash and calculated-hash (of course with better names, you shouldn't allow me to name things ever...).

In terms of things to work on and looking at the threat landscape right now, the whole Magecart/card skimming/hostile JS thing isn't going away. CSP can help us lock down the sources but there's no reliable way to know our whitelisted script has gone bad, which is why we're looking at how we could do this ourselves. SRI Reporting and Feature Policy Reporting are really high on our list of desired things.

Ok. Sounds like someone should spec and implement it. Any volunteers?

document-uri, blocked-uri, expected-hash and calculated-hash

The URL of the document in which the violation occurred is fine; JS has access to that anyway. Ditto for the expected hash value. For the blocked URL, we'd need to report the URL before redirects, just as we ought to do for CSP today. We cannot report the calculated hash value unless the endpoint opted into sharing the resource with the requesting origin.

CSP can help us lock down the sources but there's no reliable way to know our whitelisted script has gone bad

FWIW, you can certainly send a policy of script-src 'sha256-hashgoeshere', which will allow <script src="https://whatever.com/omg/a/script.js" integrity_no="sha256-hashgoeshere"> to execute (https://w3c.github.io/webappsec-csp/#external-hash). That's a perfectly reasonable approach to XSS prevention.

Sorry, I should clarify my comment about "no reliable way". All of our customers that I've delth with use a site-wide CSP and so have all other sites I've looked at. I can't recall anyone doing CSP on a page-by-page basis. Adding site-wide integrity hashes to the policy would make it enormous, even with only a small selection of script/style resources. It's either that or add the ability to generate the CSP on a per page basis. I guess I meant to say there's "no easy way" ;-)

It also presents an additional point of failure in terms of updating the script/style tag. Right now you can change the src/integrity attributes and you're done. Coupling this with CSP means another change. There is of course value in doing that, but I don't think those that want SRI reporting should have to hook it into CSP like that, especially given the restriction above.

Agreed on all other points about report field values 👍

(Since neither of you are members of WebAppSec, I have to put on my shiny chair's hat and note that this work should probably start in the WICG after you both sign the CLA on behalf of your employers/selves. :) If we get to the point of adopting it into WebAppSec, I'm sure @wseltzer and @samuelweiler can help us work through whatever IP considerations come into play.)

@devd I'm not opposed to the idea of trying but I have literally no idea where to start or what to do! I've read a lot of specs and that doesn't fill me with confidence about writing one ;-)

We cannot report the calculated hash value unless the endpoint opted into
sharing the resource with the requesting origin.

Since an SRI-protected cross-origin request has to be made in crossorigin mode anyway, presumably there could just be a separate failure case for 'resource declined to participate in CORS'?

Let's not do that, please. It's rather intentional design that a CORS failure is transparent and could have been a TCP issue or some such.

@mikewest is there an example of a spec other than CSP that uses CSP's reporting section to send its own reports? I couldn't think/find anything but maybe you know one. this might help @ScottHelme write this integration.

Not that I know of. I'd recommend that y'all define some sort of SRI report that hooks into https://www.w3.org/TR/reporting/ (similar conceptually to the way CSP does things), rather than trying to route SRI reports through CSP. Perhaps I'm misunderstanding your question?

@devd @ScottHelme Feature Policy ties in with Reporting so it might be worth looking at https://wicg.github.io/feature-policy/#reporting

@devd yeah I can do, this should be... fun :-D

@ScottHelme let me know if you need help. Would be good to have some telemetry from SRI violations.

I just learned that SRI applies to error responses too, or at least people think it should. You probably don't want an SRI violation report when your server returns 4xx or 5xx errors when you only supply the SRI hash for the response body of an expected 200 response.

The new PCI DSS 4.0 requirements dropped recently and, amongst other things, they're requiring integrity checking JS on payment pages. I wrote a blog post about the new requirements: https://scotthelme.co.uk/pci-dss-4-0-its-time-to-get-serious-on-magecart/

SRI reporting, via the Reporting API, is becoming more and more desirable. SRI is powerful to be able to mitigate an attack like Magecart, but a site operator has no hope to identify and properly resolve the underlying issue without a report to inform them it happened. Responding quickly in such an attack is of paramount importance.

Ping @mikewest as I'd like to get this off the ground and also @devd who offered to guide me previously! I used the Feature Policy text as an example thanks to @mozfreddyb, and there was also an offer of help from @rcbarnett-zz too, so I have some draft text I could put forwards for the spec.

Guidance on where/how to proceed from here would be great 👍

I think first step would be to see if there's browser interest; in the past, the push back has always been that folks can do by catching the error and logging that.

My personal take (after multiple large scale csp deployments) is that this sort of rewriting JS is extremely painful and a reporting tool makes adoption a lot easier. But, maybe instead of just violation reporting, I think we need report-only mode for sri? This can make rollout a lot easier..based on my csp experience, maybe once sri is actually enforced, the reports aren't as useful.

The other nice thing is that because reporting is now a separate spec, any change in sri won't need to rehash how to send reports.

I've done some research and wasn't able to find a way to catch the error and log it, did I miss something? I don't see a CSP SecurityPolicyViolationEvent equivalent in SRI and using onerror doesn't provide any of the necessary information.

The difference between CSP and SRI in my experience is that SRI is often provided along with a script tag. There are also many tools out there, ours included, that can take the URL of an asset and provide a script/link tag with the appropriate integrity attributes to just copy/paste. SRI is simple by comparison to CSP and a report-only feature isn't something I've seen requested.

I agree it will be much nicer to hook this in to the Reporting API rather than its own reporting mechanism.

Hey Scott,

I think reporting is a reasonable thing to add, and the integration with the Reporting API should be relatively straightforward. The only nuance that comes to mind immedietly is that the report cannot reveal the actual hash of the remote resource, merely that it did not match the hash the page knows. Likewise, we likely cannot distinguish between a lack of CORS headers and a content mismatch, as both should look like a network error.

At the same time, reporting seems more valuable if it's coupled with an enforcement mechanism. AFAIR, we removed require-sri-for from CSP a while ago as no one shipped it (and no one shipped it at least partially because we had no story for modules/import). Is that something you're interested in picking up as well?

/cc @camillelamy to get this on her team's radar; reporting seems fairly small from an implementation perspective, perhaps she can fit it in? Enforcement itself is straightforward, but the module discussion might require more time than they have...

We are generally supportive of specifying that idea. I want to note that Firefox does not plan to ship the Reporting API anytime soon. This will need more spec work before we can comment any further.

I want to note that Firefox does not plan to ship the Reporting API anytime soon.

That's unfortunate.

I would prefer not to implement an extension to CSP's reporting mechanism for SRI, but to rely on the more generalized mechanism so we can reason about reports the browser generates in one place.
https://mdn.github.io/dom-examples/reporting-api/deprecation_report.html suggests that Nightly supports ReportingObserver at least: perhaps that in-page script interface is something that could be shipped on a tigher schedule than the headers and HTTP delivery mechanisms?

This will need more spec work before we can comment any further.

Is "this" reporting, or the SRI extension?

I want to note that Firefox does not plan to ship the Reporting API anytime soon.

That's unfortunate.

I would prefer not to implement an extension to CSP's reporting mechanism for SRI, but to rely on the more generalized mechanism so we can reason about reports the browser generates in one place. https://mdn.github.io/dom-examples/reporting-api/deprecation_report.html suggests that Nightly supports ReportingObserver at least: perhaps that in-page script interface is something that could be shipped on a tigher schedule than the headers and HTTP delivery mechanisms?

I agree. It would be preferable to build this upon the Reporting API.
Btw, the Reporting interfaces do exist on Nightly, but our implementation is currently incompatible and outdated.

This will need more spec work before we can comment any further.

Is "this" reporting, or the SRI extension?

Mozilla considers the Reporting API worth prototyping.
There is no official Mozilla position on the proposed SRI extension, but I also consider it worth speccing out further :)

At the same time, reporting seems more valuable if it's coupled with an enforcement mechanism. AFAIR, we removed require-sri-for from CSP a while ago as no one shipped it (and no one shipped it at least partially because we had no story for modules/import). Is that something you're interested in picking up as well?

This has evolved since the require-sri-for removal; scoping this just to JS there's now the ability to expose this information via Import maps which Firefox supports in 102.

The only nuance that comes to mind immedietly is that the report cannot reveal the actual hash of the remote resource, merely that it did not match the hash the page knows.

Given that SRI requires crossorigin=anonymous, what's the concern with returning the actual hash? It's not critically important to report it, but it could help site operators if it was in the report.

Likewise, we likely cannot distinguish between a lack of CORS headers and a content mismatch, as both should look like a network error.

I can't see a value to indicating that it failed due to CORS, simply knowing that the integrity check failed is the main goal.

At the same time, reporting seems more valuable if it's coupled with an enforcement mechanism. AFAIR, we removed require-sri-for from CSP a while ago as no one shipped it (and no one shipped it at least partially because we had no story for modules/import). Is that something you're interested in picking up as well?

The biggest issue I saw with the concept of require-sri-for was that it was all or nothing. For example, I could never use it because Stripe JS does not support SRI and Stripe have indicated that they may never support it [source]. Enforcement would be nice, perhaps on a more flexible basis, but it seems outside of the scope of SRI to defend against an attacker that can inject arbitrary HTML into the page, say a script tag with no integrity attribute which should be dealt with by CSP? For now, the demand we have is for site operators to know when scripts they are loading with integrity attributes are failing integrity validation.

Given that SRI requires crossorigin=anonymous, what's the concern with returning the actual hash? It's not critically important to report it, but it could help site operators if it was in the report.

This ended up confusingly phrased, apologies. If there's a CORS error (e.g. the resource doesn't opt-in), then we can't reveal the resource's content in the report. I agree that if the resource does opt-in to being readable cross-origin, then the site could just fetch it, so there's no additional risk in revealing its hash.

The biggest issue I saw with the concept of require-sri-for was that it was all or nothing.

Isn't that what the PCI recommendations you've pointed to are suggesting should be required?

... it seems outside of the scope of SRI to defend against an attacker that can inject arbitrary HTML into the page, say a script tag with no integrity attribute which should be dealt with by CSP

The two mechanisms do different things, but seem quite complementary. CSP can, for example, give you the ability to limit your scripts to known-good sources. SRI allows you to further assert that those sources match your content expectations. Some browsers support layering the two directly, which means you can get some certainty about scripts loading on your page with a hash-based policy

Isn't that what the PCI recommendations you've pointed to are suggesting should be required?

There are different levels of compliance for PCI and more specifically the wording of the PCI DSS SAQ A v4.0 requirement (link), which is for companies like us that use a TPSP like Stripe is:

A method is implemented to assure the integrity of each script.

The full PCI DSS v4.0 (link) provides some examples of how you can achieve that requirement, but note that SRI is not required, only a 'method to assure the integrity':

Examples
The integrity of scripts can be enforced by several
different mechanisms including, but not limited to:
• Sub-resource integrity (SRI), which allows the
consumer browser to validate that a script has
not been tampered with.
• A CSP, which limits the locations the
consumer browser can load a script from and
transmit account data to.
• Proprietary script or tag-management
systems, which can prevent malicious script
execution.

Given the opposition shown by Stripe to SRI in the past and their stated update cadence, it would seem that SRI is out and they're likely to provide some other method that doesn't require regular updates by the site operator. This does still leave all other scripts as the responsibility of the site operator though and SRI seems like the best candidate for an easy and low maintenance solution.

Given the opposition shown by Stripe to SRI in the past and their stated update cadence

I think we could solve this by creating a less-static integrity mechanism. I would still like to see something along the lines of https://github.com/mikewest/signature-based-sri (updated, of course, in light of SXG, etc). Someone should spend some time on that. :)

Wouldn't reporting SRI success/failure end up leaking information? We wouldn't want to reveal whether it's CSP, CORS, SRI, the server, DNS, etc.

I'd hope that SRI reports don't leak any of that information. If the script fails to load because of any of the reasons you've specified, it wouldn't result in an SRI error would it? At least, I wouldn't expect it to...

If the DNS lookup for the script host fails, there's nothing to integrity check. Likewise for a CSP block or a CORS failure. If the server returned a status code other than 200, I also wouldn't except an integrity check to take place. Similarly, any other TCP/HTTP/TLS errors/failures should result in no integrity check and thus no report.

The only time I'd ever expect to see a report sent is if, after the browser successfully loaded the script and was about to run it, the integrity check failed.

Right, it's not clear to me we want to expose that distinction.

My understanding is that error reporting is for integrity check failure. A network error (which is what a cors error would look like) wouldn't cause an integrity error. So, I believe there shouldn't be any leak (since we already generate an error in JS and so had to think through this for that...if there's a leak, we would have the same problem in JS)

There's already an error in JS? How does that even work timing-wise? (Let alone specification-wise, since I'm pretty sure that's not properly defined.)

I want to point out that we're dealing with two kinds of discussions now. The "Maybe hash-based integrity is not serving the people, because many useful third-party scripts require more agility" and "Maybe developers just need better reporting". Let's make sure this conversation is about reporting first and discuss other opportunities elsewhere. Thanks for pointing out the right kind of relevant work & required reading material, @mikewest! :)

My understanding is that the failed load currently gets a NetworkError.
element.addEventlistener(error, ...) can be done, but the platform does not expose where the error occured.

Given that SRI requires crossorigin=anonymous, we can assume any code on that web page could fetch() the resource themselves, compute the hash and see if the failure has been an integrity failure. What's the danger in exposing this through an event?

The risk is minor, but it's not something Fetch is equipped to do at this point.

See WICG/signature-based-sri/issues/28 for another discussion of this feature request.