As some files are changed during compilation, before beeing deployed in the public assets directory, it may be easier more efficient to compute those hash locallly.

In fact, as we already compute a hash based on the content, it would just be a question of "hashing strategy" (similar to the user password hashing behaviour in Security)

AssetMapper uses xxh128 hasher because it's very fast. See https://github.com/search?q=repo%3Asymfony%2Fsymfony%20path%3A%2F%5Esrc%5C%2FSymfony%5C%2FComponent%5C%2FAssetMapper%5C%2F%2F%20hash&type=code

SRI only supports SHA-256, SHA-384, and SHA-512. See https://w3c.github.io/webappsec-subresource-integrity/#hash-functions

AKAIK, import maps do not support intergrity hashes.

And that's where the majority of 3rd party assets are referenced.

The other assets (endpoints and CSS mainly) are changed during compilation, so we cannot use SRI computed elsewhere for that.

Plus, it's really useful for Remote Resource, not as much for self serve resource.

I'm closing this because as @ph-il said, SRI is really useful when embedding third-party assets ... but with AssetMapper we're serving assets from our own servers.

What we might need is to have checksums of the assets downloaded from jsDeliver. But that's a completely different feature. Thanks!

Hi,

SRI is really useful when embedding third-party assets

No, if a malicious user change the script content stored in your server or CDN, it's a security risk.

Like Webpack Encore, the Asset Mapper should have a enableIntegrityHashes feature.

@pierreboissinot

I just opened a PR, with some basic implementation / first ideas.. if you want to contribute :)