Intent to Ship: CSP require-sri-for for scripts

[Yoav Weiss (@Shopify)]

Contact emails

yoav...@chromium.org

Explainer

https://github.com/w3c/webappsec-subresource-integrity/pull/129#:~:text=for%20some%20assets.-,require%2Dsri%2Dfor%20CSP%20directive,-Subresource%2DIntegrity%20

Specification

https://github.com/w3c/webappsec-subresource-integrity/pull/129

The feature and PR were discussed at the WebAppSec WG call.

No objection beyond questions on whether we'd need to expand this to cover stylesheets as well. We'd be able to do that in the future (as a separate intent) if needed.

Summary

The `require-sri-for` 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. This intent covers the "script" value of this directive.

Blink component

Blink>SecurityFeature>ContentSecurityPolicy

TAG review

https://github.com/w3ctag/design-reviews/issues/1048

TAG review status

Pending - No response just yet

Risks

Interoperability and Compatibility

On the compatibility front:

This directive was already implemented in the past, and there are some developer docs that still describe it. The current PR and implementation did not diverge from the past implementation.

If developers deployed the feature in the past and are now relying on it not really working, that may result in surprising breakage. The HTTPArchive shows 0.0011% of page responses (178 out of 15760519) have an existing `require-sri-for` directive. That's an upper bound - only those that enforce scripts, and have no integrity attributes on some scripts may get broken.

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/1173)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/458)

Web developers: Shopify is interested in this. I suspect PCIv4 would make some developers interested in making sure their documents' scripts have complete integrity checks.

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

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

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

Yes

https://wpt.fyi/results/content-security-policy/tentative/require-sri-for?label=experimental&label=master&aligned

Flag name on about://flags

None

Finch feature name

CSPRequireSRIFor

Requires code in //chrome?

False

Estimated milestones

Shipping on desktop	135
DevTrial on desktop	134
Shipping on Android	135
DevTrial on Android	134
Shipping on WebView	135

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5090023365672960?gate=5186570942152704

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJUygAmobR9dRkDr%3DBWQ1h5hv2Lj3WUFN31QZF360A47A%40mail.gmail.com

This intent message was generated by Chrome Platform Status.

[Yoav Weiss (@Shopify)]

On Thursday, February 20, 2025 at 11:47:00 AM UTC+1 Yoav Weiss wrote:

Contact emailsyoav...@chromium.org

Explainerhttps://github.com/w3c/webappsec-subresource-integrity/pull/129#:~:text=for%20some%20assets.-,require%2Dsri%2Dfor%20CSP%20directive,-Subresource%2DIntegrity%20

Specificationhttps://github.com/w3c/webappsec-subresource-integrity/pull/129

The feature and PR were discussed at the WebAppSec WG call.

No objection beyond questions on whether we'd need to expand this to cover stylesheets as well. We'd be able to do that in the future (as a separate intent) if needed.

Summary

The `require-sri-for` 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. This intent covers the "script" value of this directive.

Blink componentBlink>SecurityFeature>ContentSecurityPolicy

TAG reviewhttps://github.com/w3ctag/design-reviews/issues/1048

TAG review statusPending - No response just yet

Risks

Interoperability and Compatibility

On the compatibility front:

This directive was already implemented in the past, and there are some developer docs that still describe it. The current PR and implementation did not diverge from the past implementation.

If developers deployed the feature in the past and are now relying on it not really working, that may result in surprising breakage. The HTTPArchive shows 0.0011% of page responses (178 out of 15760519) have an existing `require-sri-for` directive. That's an upper bound - only those that enforce scripts, and have no integrity attributes on some scripts may get broken.

Doing some more HA digging I found that it's 153 sites, which is not significantly different.

I downloaded their URLs and started going to these sites with the feature enabled.

Of those 153, 22 had any blocked assets, 9 had broken functionality or layout and 1 had missing ads.
Non-visiblity broken but blocked sites mostly had their analytics blocked.

Extrapolating that data brings us to 0.000158% for any blocked assets, and 0.000065% for broken functionality.

I'm planning to reach out to the broken sites and make them aware of this change. Many of them seem to be coming from a single provider (similar site and breakage). 

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/1173)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/458)

Web developers: Shopify is interested in this. I suspect PCIv4 would make some developers interested in making sure their documents' scripts have complete integrity checks.

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

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?Yes

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

https://wpt.fyi/results/content-security-policy/tentative/require-sri-for?label=experimental&label=master&aligned

Flag name on about://flagsNone

Finch feature nameCSPRequireSRIFor

Requires code in //chrome?False

Estimated milestonesShipping on desktop135DevTrial on desktop134Shipping on Android135DevTrial on Android134Shipping on WebView135

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Statushttps://chromestatus.com/feature/5090023365672960?gate=5186570942152704

Links to previous Intent discussionsIntent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJUygAmobR9dRkDr%3DBWQ1h5hv2Lj3WUFN31QZF360A47A%40mail.gmail.com

[Yoav Weiss (@Shopify)]

On Thursday, February 20, 2025 at 1:56:59 PM UTC+1 Yoav Weiss wrote:

On Thursday, February 20, 2025 at 11:47:00 AM UTC+1 Yoav Weiss wrote:

Contact emailsyoav...@chromium.org

Explainerhttps://github.com/w3c/webappsec-subresource-integrity/pull/129#:~:text=for%20some%20assets.-,require%2Dsri%2Dfor%20CSP%20directive,-Subresource%2DIntegrity%20

Specificationhttps://github.com/w3c/webappsec-subresource-integrity/pull/129

The feature and PR were discussed at the WebAppSec WG call.

No objection beyond questions on whether we'd need to expand this to cover stylesheets as well. We'd be able to do that in the future (as a separate intent) if needed.

Summary

The `require-sri-for` 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. This intent covers the "script" value of this directive.

Blink componentBlink>SecurityFeature>ContentSecurityPolicy

TAG reviewhttps://github.com/w3ctag/design-reviews/issues/1048

TAG review statusPending - No response just yet

Risks

Interoperability and Compatibility

On the compatibility front:

This directive was already implemented in the past, and there are some developer docs that still describe it. The current PR and implementation did not diverge from the past implementation.

If developers deployed the feature in the past and are now relying on it not really working, that may result in surprising breakage. The HTTPArchive shows 0.0011% of page responses (178 out of 15760519) have an existing `require-sri-for` directive. That's an upper bound - only those that enforce scripts, and have no integrity attributes on some scripts may get broken.

Doing some more HA digging I found that it's 153 sites, which is not significantly different.

I downloaded their URLs and started going to these sites with the feature enabled.

Of those 153, 22 had any blocked assets, 9 had broken functionality or layout and 1 had missing ads.
Non-visiblity broken but blocked sites mostly had their analytics blocked.

Extrapolating that data brings us to 0.000158% for any blocked assets, and 0.000065% for broken functionality.

I'm planning to reach out to the broken sites and make them aware of this change. Many of them seem to be coming from a single provider (similar site and breakage). 

I also found ~3500 sites that have the `require-sri-for` string in their response bodies (and hence may have it applied).

I put together a script that so far scanned ~1800 of them and found no blocked assets. So, it seems like the risk is very low on that front.

[Mike Taylor]

Thanks, I appreciate you digging in to understand the possible risks. My understanding of the compat risk goes something like (please let me know if I'm missing something):

1. This feature never really shipped, but was implemented behind a flag.

2. Early adopter developers (or menu framework authors?) added require-sri-for for some scripts that they wanted to lock down (to prevent 3rd-party attackers from modifying them, etc).

3. Now, you actually ship the feature.

That means the risks are:

a) Some CDN was compromised at some point, and now some sketchy scripts will fail to load. Seems like that's security positive, even if it surprises users or developers.

b) Perhaps more likely, a page was redesigned and they updated their analytics provider but didn't remember to add hashes. Now some things don't work.

From your sheet (which is great, thanks), it seems like largest impact is busted menus. Is this a single library? Or common pattern?

 

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/1173)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/458)

Web developers: Shopify is interested in this. I suspect PCIv4 would make some developers interested in making sure their documents' scripts have complete integrity checks.

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

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?Yes

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

https://wpt.fyi/results/content-security-policy/tentative/require-sri-for?label=experimental&label=master&aligned

Flag name on about://flagsNone

Finch feature nameCSPRequireSRIFor

Requires code in //chrome?False

Estimated milestonesShipping on desktop135DevTrial on desktop134Shipping on Android135DevTrial on Android134Shipping on WebView135

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Statushttps://chromestatus.com/feature/5090023365672960?gate=5186570942152704

Links to previous Intent discussionsIntent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJUygAmobR9dRkDr%3DBWQ1h5hv2Lj3WUFN31QZF360A47A%40mail.gmail.com

This intent message was generated by Chrome Platform Status.

--
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/8d3107ca-61cc-47f6-badd-8bc6a1f30145n%40chromium.org.

[Yoav Weiss (@Shopify)]

Tiny correction: they added it to the document's CSP, not specific scripts.  

(to prevent 3rd-party attackers from modifying them, etc).

3. Now, you actually ship the feature.

That means the risks are:

a) Some CDN was compromised at some point, and now some sketchy scripts will fail to load. Seems like that's security positive, even if it surprises users or developers.

b) Perhaps more likely, a page was redesigned and they updated their analytics provider but didn't remember to add hashes. Now some things don't work.

I suspect it's 

c) they added the header but never actually tested with the feature enabled, as it never shipped.

It seems like they added the CSP header, but never added an "integrity" attribute to many/most of their scripts.

 

From your sheet (which is great, thanks), it seems like largest impact is busted menus. Is this a single library? Or common pattern?

It seems like a common provider. 6 out of the 9 sites with issues are Canadian health/edu related sites. 

[Mike Taylor]

Breaking health/edu-releated sites is not good... When broken, is it cosmetic, or are the links in the menu still accessible? (I see you're gathering contact info - let me know if you need help with that.)

Assuming we can sort out the menu breakage somehow, I think for the rest - the best we can do is roll it out and be ready to killswitch if needed.

[Yoav Weiss (@Shopify)]

Indeed, although I'm not sure how load-bearing they are.. 

When broken, is it cosmetic, or are the links in the menu still accessible? (I see you're gathering contact info - let me know if you need help with that.)

It seems like the desktop view is functional, but the mobile view's hamburger menu is not working (at least in some cases).

[Yoav Weiss (@Shopify)]

FWIW, I'm planning to discuss a syntax change at next week's WebAppSec meeting, that can help us avoid these compat issues.

[Yoav Weiss (@Shopify)]

Following discussions at WebAppSec and the WAICT proposal, I'm renaming the directive to `integrity-required`. (CL)

That would also reduce the compatibility risk to zero AFAICT.

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

[Domenic Denicola]

Great to hear!

I see you've already updated the spec PR. My instinct is that we should give folks a week-ish to react to the new name, finish the spec review, etc. What do you think?

(Also, I can't quite understand what's blocking the spec PR from landing... I guess there's still some discussion about whether the bar is "2 interested implementers" or "2 actively implementing implementers"? Maybe it's worth poking to see if you can get more clarity on that?)

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/8d3107ca-61cc-47f6-badd-8bc6a1f30145n%40chromium.org.

--

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/49037f78-2795-4d2e-9645-361e632c61f7n%40chromium.org.

[Yoav Weiss (@Shopify)]

On Mon, Mar 24, 2025 at 6:45 AM Domenic Denicola <dom...@chromium.org> wrote:

Great to hear!

I see you've already updated the spec PR. My instinct is that we should give folks a week-ish to react to the new name, finish the spec review, etc. What do you think?

Normally I would think this makes perfect sense. But given the 136 branch point a week from now, I prefer one of the two options:
* Enable the flag in 136 before it branches and revert in the unlikely case there's some disagreement on the spelling.

* Get help from Google folks to Finch enable it in 136 after branch point.

 

Does that make sense?

(Also, I can't quite understand what's blocking the spec PR from landing... I guess there's still some discussion about whether the bar is "2 interested implementers" or "2 actively implementing implementers"? Maybe it's worth poking to see if you can get more clarity on that?)

I believe it's held back on getting SRI L2 to FPWD (as a future Living Standard), and then potentially on getting a working mode agreed on, and for the PR to meet it. So it may take a while to land the PR.

+Mike West - Is my understanding correct?

[Domenic Denicola]

On Mon, Mar 24, 2025 at 4:37 PM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

On Mon, Mar 24, 2025 at 6:45 AM Domenic Denicola <dom...@chromium.org> wrote:

Great to hear!

I see you've already updated the spec PR. My instinct is that we should give folks a week-ish to react to the new name, finish the spec review, etc. What do you think?

Normally I would think this makes perfect sense. But given the 136 branch point a week from now, I prefer one of the two options:
* Enable the flag in 136 before it branches and revert in the unlikely case there's some disagreement on the spelling.

This option sounds good to me. LGTM1.

[Mike Taylor]

On 3/24/25 10:24 PM, Domenic Denicola wrote:

On Mon, Mar 24, 2025 at 4:37 PM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

On Mon, Mar 24, 2025 at 6:45 AM Domenic Denicola <dom...@chromium.org> wrote:

Great to hear!

I see you've already updated the spec PR. My instinct is that we should give folks a week-ish to react to the new name, finish the spec review, etc. What do you think?

Normally I would think this makes perfect sense. But given the 136 branch point a week from now, I prefer one of the two options:
* Enable the flag in 136 before it branches and revert in the unlikely case there's some disagreement on the spelling.

This option sounds good to me. LGTM1.

Me too, LGTM2

[Chris Harrelson]

LGTM3

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0b112bbd-5132-4d64-a85f-78afb6ba3005%40chromium.org.

[Yoav Weiss (@Shopify)]

Thanks for reviewing!!

In discussions with Mozilla folk, we eventually landed on a very different API shape, to enable them to expand the concept of "integrity policy", rather than doing this as a one-off CSP directive. As a result, I'd need to revamp the implementation and spec. I'll let y'all know when it's time to reapprove (I can do that as a separate intent, if that would be more convenient)

[Yoav Weiss (@Shopify)]

Hey folks!

I now have a CL for Integrity-Policy (that also removes the require-sri-for implementation), and a PR is being reviewed.

Should I send a new intent for this? Or can we assume that this intent is still valid, despite the now inaccurate name?

[Mike Taylor]

Given that this is described as "very different", I think a new I2S would be helpful. Or if you decide that's too annoying, at the very least could you write up a minimal explainer (inline is fine) that describes the diff from require-sri-for, and create a new chromestatus entry?

[Yoav Weiss (@Shopify)]

Makes sense! I'll send a new intent.