Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Preload and SRI #127
We, Chrome, have some difficulty to support script preload with SRI. Here is the story:
We spent months to solve the issue in our codebase, but we've given it up due to complexity the solution would bring.
I think, instead, we could ask web developers to specify the integrity value at the link element. For example,
What do you think about this idea?
As we discussed earlier in the week, I think it's reasonable to allow developers to specify an
I think it's unfortunate to place extra complexity on users, but understand that codebase complexity may not be trivial as well.
Would it be sufficient to include a preload signal that indicates that SRI would be needed, and what hash function would be used? That way the SRI verification can only be done when the
The hint will enable the engine to collect the right hash value of the resource without storing its bytes until it is matched with a script/style.
+1 for supporting integrity enforcement on preload.
Related discussion: w3c/webappsec-subresource-integrity#26
Re, function vs value: are there use cases where value would enable enforcement where it's not possible today? E.g. if I preload a response that's later consumed via fetch(), it would be nice to defer to preload to do the validation, albeit there is the wrinkle here that if validation fails than preload can't simply drop the bytes but would instead need to return a failed response to fetch()?
@yoavweiss I understand your motivation, but I'm also a little hesitant of overloading and special casing "integrity" value here with hashes. If we go down this route, perhaps we should consider a different attribute name?
referenced this issue
Aug 28, 2018
Per discussion at TPAC 2018 on 10/25/2018:
@yoavweiss , can you please edit the spec or find an editor to make this update?