Subresource Reporting

[yoavweiss]

Introduction

Complex web application 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 - context) require that web applications keep an inventory of all the scripts they download and execute.

This is a proposal for a new web platform feature on top of the Reporting API, that would enable web developers to create and maintain such inventories in a secure manner.

Problem

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. We need a better path.

Proposal

A new Reporting API feature could be used to send reports of all scripts executed in the context of the relevant document, including their URLs and their hashes (for CORS-enabled resources).

Read the complete Explainer for more details.

Feedback

I welcome feedback in this thread, but encourage you to file bugs against the Explainer repo.

[rektide]

I don't love how this is a manifest of things loaded (data) but also a protocol, a way to send it somewhere. Why build a new side channel for specific data like that? It feels like this should be an unopinionated data source and there can be various transports and perhaps this reporting api transport can be one example way of sending. But combining the means to access with the specific new transport here feels un-giod, creating more fractal ways of information exposure.

See also works like Content Index. Different use case but it nicely exposed API for registering & discovering/listing content. I feel like this use case would be more broadly & better served by having a similar pattern of registration, rather than being tied to a specific means of sending data upstream.

[rsolomakhin]

Hi Yoav, are extension scripts in scope of this proposal?

[yoavweiss]

They are not. I probably should state that more explicitly.