Following discussions <https://github.com/w3c/webappsec/blob/main/meetings/2025/2025-03-19-minutes.md#require-sri-for-compatibility-and-spelling> at WebAppSec and the WAICT <https://docs.google.com/document/d/16-cvBkWYrKlZHXkWRFvKGEifdcMthUfv-LxIbg6bx2o/edit?tab=t.0> proposal, I'm renaming the directive to `integrity-required`. (CL <https://chromium-review.googlesource.com/c/chromium/src/+/6382018>)
That would also reduce the compatibility risk to zero AFAICT. On Monday, March 10, 2025 at 10:55:02 AM UTC+1 Yoav Weiss wrote: > FWIW, I'm planning to discuss > <https://github.com/w3c/webappsec/issues/668#issuecomment-2709995028> a > syntax change at next week's WebAppSec meeting, that can help us avoid > these compat issues. > > On Tue, Feb 25, 2025 at 7:54 PM Yoav Weiss (@Shopify) < > yoavwe...@chromium.org> wrote: > >> >> >> On Tue, Feb 25, 2025 at 6:08 PM Mike Taylor <miketa...@chromium.org> >> wrote: >> >>> >>> On 2/24/25 4:24 PM, Yoav Weiss (@Shopify) wrote: >>> >>> >>> >>> On Mon, Feb 24, 2025 at 7:18 PM Mike Taylor <miketa...@chromium.org> >>> wrote: >>> >>>> On 2/21/25 8:33 AM, Yoav Weiss (@Shopify) wrote: >>>> >>>> >>>> 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 emailsyoavwe...@chromium.org >>>> >>>> Explainerhttps://github.com/w3c/webappsec-subresource-inte >>>> grity/pull/129#:~:text=for%20some%20assets.-,require%2Dsr >>>> i%2Dfor%20CSP%20directive,-Subresource%2DIntegrity%20 >>>> >>>> Specificationhttps://github.com/w3c/webappsec-subresource- >>>> integrity/pull/129 >>>> >>>> >>>> >>>> The feature and PR were discussed >>>> <https://github.com/w3c/webappsec/blob/main/meetings/2025/2025-02-19-minutes.md#reviving-require-sri-for> >>>> >>>> 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 >>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ESecurityFeature%3EContentSecurityPolicy%22> >>>> >>>> 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 >>>> <https://udn.realityripple.com/docs/Web/HTTP/Headers/Content-Security-Policy/require-sri-for> >>>> >>>> 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 >>>> <https://docs.google.com/spreadsheets/d/1NlFHLytc8lQcdP5FXXDltKEPQVE0e8oyjw9k1S-9KPI/edit?usp=sharing> >>>> 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. >>>> >>>> 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 >>>> >>> 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. >>> >>> Breaking health/edu-releated sites is not good... >>> >> 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). >> >>> 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. >>> >>> >>>> >>>> >>>> >>>> >>>> *Gecko*: No signal (https://github.com/mozilla/st >>>> andards-positions/issues/1173) >>>> >>>> *WebKit*: No signal (https://github.com/WebKit/sta >>>> ndards-positions/issues/458) >>>> >>>> *Web developers*: Shopify is interested in this. I suspect PCIv4 >>>> <https://docs.google.com/document/d/1RcUpbpWPxXTyW0Qwczs9GCTLPD3-LcbbhL4ooBUevTM/edit?tab=t.0> >>>> 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 >>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>> ?Yes >>>> >>>> https://wpt.fyi/results/content-security-policy/tentative/ >>>> require-sri-for?label=experimental&label=master&aligned >>>> <https://chromium-review.googlesource.com/c/chromium/src/+/5877633> >>>> >>>> >>>> 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 >>>> <https://chromestatus.com/>. >>>> >>>> -- >>>> 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+unsubscr...@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 >>>> >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8d3107ca-61cc-47f6-badd-8bc6a1f30145n%40chromium.org?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> -- 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+unsubscr...@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.
