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-integrity/pull/129#:~:text=for%20some%20assets.-,require%2Dsri%2Dfor%20CSP%20directive,-Subresource%2DIntegrity%20
<https://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
<https://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
<https://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 (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
<https://github.com/mozilla/standards-positions/issues/1173>)
/WebKit/: No signal
(https://github.com/WebKit/standards-positions/issues/458
<https://github.com/WebKit/standards-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
<https://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
<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/cf7cb3ca-a1f7-4834-a069-b24338e98ad1%40chromium.org.
