Intent to Prototype: Subresource Reporting for scripts

[Yoav Weiss (@Shopify)]

Contact emails

yoav...@chromium.org

Explainer

https://github.com/yoavweiss/subresource-reporting?tab=readme-ov-file#subresource-reporting

Specification

Not yet, but soon.

Summary

Complex web applications often need to keep tabs of the subresources that they download, for security purposes. In particular, upcoming industry standards and best practices (e.g. PCI-DSS v4) require that web applications keep an inventory of all the scripts they download and execute. This feature builds on the Reporting API to report the URLs and hashes (for CORS/same-origin) of all the script resources that the document loads.

Blink component

Blink>ReportingObserver

Motivation

Web developers load many different script assets to their sites, and those scripts can then load other assets. Some of those assets are versioned and their content's integrity can be validated using Subresource Integrity or using Content Security Policy hashes. But other assets are dynamic, ever-green scripts that can be updated by their provider at any moment. The web platform has no means of validating the integrity of such scripts, neither in reporting nor in enforcement mode. At the same time, upcoming security standards require web developers to maintain an up to date inventory of all scripts that execute in the context of their payment page documents, and have a mechanism to validate their integrity. In the absence of better mechanisms, developers and merchants will need to settle for lower fidelity security guarantees — e.g. offline hash verification through crawling. Such mechanisms leave a lot to be desired in terms of their coverage, while at the same time add a lot of implementation complexity.

Initial public proposal

https://github.com/WICG/proposals/issues/182

TAG review

Not yet

TAG review status

Soon

Risks

Interoperability and Compatibility

As this is a new feature activated through an HTTP header, I don't believe there's any compatibility risk associated with it.

As for interoperability, it's a bit early to say but casually talking to Mozilla and Webkit folks about it didn't trigger any alarms on their end.

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

None

Is this feature fully tested by web-platform-tests?

Yes

Flag name on about://flags

None

Finch feature name

SubresourceReporting

Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/377830102

Estimated milestones

M133

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6337535507431424?gate=5620293283086336

This intent message was generated by Chrome Platform Status.

[Rick Byers]

Sounds cool Yoav, and PCI-DSS v4 compliance does seem like a generally useful thing to be doing to help better secure payments on the web. Thank you for driving this!

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSK_3rddBZ16wCBCuJR3f2a9%3DGSWDH-azFbmHi5dQK%2BPqw%40mail.gmail.com.

[Yoav Weiss (@Shopify)]

As a result of WebAppSec discussions, this effort is moving to a PR on CSP. 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.