Revive require-sri-for for scripts

[yoavweiss]

This ~reverts https://github.com/w3c/webappsec-subresource-integrity/pull/82/files, which reverted require-sri-for.

It only includes the script token, as it has a clear use case.

I believe the reasons for removing require-sri-for are losing ground:

• We can now set integrity for dynamic ES modules
• Signature-based SRI will enable us to set integrity checks for evergreen scripts

Integrity checks for workers are still missing, but there's work underway to enable importmaps in workers which will give us that, at least for some assets.

require-sri-for CSP directive

Subresource-Integrity (SRI) enables developers to make sure the assets they intend to load are indeed the assets they are loading. But there's no current way for developers to be sure that all of their scripts are validated using SRI.

The require-sri-for CSP directive gives developers the ability to assert that every resource of a given type needs to be integrity checked. If a resource of that type is attempted to be loaded without integrity metadata, that attempt will fail and trigger a CSP violation report.

Example usage

A developer that wants to validate that all of their script resources have integrity checks will be able to add a CSP header similar to:

Content-Security-Policy: require-sri-for 'script' 

(Or the equivalent <meta> tag)

From that point, any external script that is fetched without a valid integrity attribute (that is, one that translates into non-empty integrity metadata) or with a "no-cors" request mode, will not be loaded.
It will also trigger a "securitypolicyviolation" event, as well as a CSP report.

---

Preview | Diff

[yoavweiss]

Further work on this would require:

• Ensuring data/blob URLs get a free pass
• Ensuring Signature-based SRI is considered "integrity metadata".

We'd also need tests for the above

[yoavweiss]

• Ensuring data/blob URLs get a free pass

Done

• Ensuring Signature-based SRI is considered "integrity metadata".

The relevant Fetch parts mean that any string is considered a non-empty integrity metadata.
At the same time, we explicitly test that unknown signatures cause a request to be blocked.

[yoavweiss]

The relevant Fetch parts mean that any string is considered a non-empty integrity metadata.
At the same time, we explicitly test that unknown signatures cause a request to be blocked.

done!

[mozfreddyb]

How likely is it that we expand the list of known tokens? Otherwise a simple string-equals match would suffice.

[yoavweiss]

Previously the list also included "style". As I don't have a clear use case for it, I didn't add it here.

We could drop this to be a simple equality check now, and expand to a list if/when the time comes.

[annevk]

What should the behavior be in user agents which don't understand the new type?

This suggestion would make them not enforce anything at all, which seems suboptimal?

[yoavweiss]

I think this is the way CSP directives are currently defined, and that enabled us to expand them over time.

Not enforcing anything on unknown types would enable us to expand the list overtime if needed. What's the alternative you see?

[yoavweiss]

Thinking through @annevk's other comment, workers may be a good candidate for near-future expansion of the list.

[mozfreddyb]

With my editor hat on, I think this passes review.
With my Mozilla dinosaur hat on: We may want to align such that we have more than one implementation in planning before we merge this. How fitting that the topic is on the webappsec agenda for this week.

[mikewest]

On the process question @mozfreddyb raised above:

We discussed this in the WebAppSec WG yesterday (minutes at https://github.com/w3c/webappsec/blob/main/meetings/2025/2025-02-19-minutes.md#reviving-require-sri-for). Generally, folks on the call (and folks I've talked to elsewhere) are on board with this functionality.

I'd like to wait to land this in the spec until we've kicked off the adoption process for this work; it's quite clearly covered by our current charter, but I'd like to formally get the ball rolling on an SRI Level 2 we can continually update under the new(ish) W3C publication process. Once that's in place, adding this as a feature to that new workstream should be straightforward.

@simoneonofri is going to send out an email to the list to that effect based on yesterday's conversation, and if all goes well, I think we can get this in by March.

Does that work for you, @mozfreddyb and @yoavweiss?

[yoavweiss]

Does that work for you?

Yeah, thank you! :)

[mozfreddyb]

Yes, but specifically, once we move to a Living Standard I would like us to ensure that we have more than 1 implementation interested and with a positive standards position before merging any changes here and elsewhere

[mikewest]

@mozfreddyb: I suspect we'd generally want to end up with something like https://whatwg.org/working-mode, which sets different bars for different kinds of changes.

That said, you're editing this spec, and I think that gives you a reasonable amount of freedom to interpret when something is supported-enough to land.