我最近发现了以下nifty little site，用于为外部加载的资源生成SubResource Integrity（SRI）标签。例如，输入最新的jQuery URL（https://code.jquery.com/jquery-3.3.1.min.js），将获得以下<script>标签：
<script src="https://code.jquery.com/jquery-3.3.1.min.js" integrity="sha256-FgpCb/KJQlLNfOu91ta32o/NMZxltwRo8QtmkMRdAu8= sha384-tsQFqpEReu7ZLhBV2VZlAu7zcOV+rXbYlF2cqB8txI/8aZajjp4Bqd+V6D5IgvKT sha512-+NqPlbbtM1QqiK8ZAo4Yrj2c4lNQoGv8P79DPtKzj++l5jnN39rHA/xsqn8zE9l0uSoxaCdrOgFs6yjyfbBxSg==" crossorigin="anonymous"></script>
我了解SRI哈希的目的，并且我知道它们可以使用不同的哈希大小（256位，384位或512位），但是我以前从未见过像这一样一次使用这三种哈希。深入MDN docs，我发现
完整性值可能包含多个由空格分隔的哈希值。如果资源与那些哈希值之一匹配，则会被加载。
但是该匹配执行得如何呢？在一篇SO帖子中回答多个问题的时间...
integrity和<script>旁边的任何标签上使用<link>属性。我特别想知道诸如<img>，<source>等多媒体标签。答案 0 :(得分：4)
- 浏览器是否尝试首先匹配最长的哈希（因为它比较安全），或者首先匹配最短的哈希（因为它更快）？
每https://w3c.github.io/webappsec-subresource-integrity/#agility，“用户代理将在列表中选择最强的哈希函数”。
- 真的会期望一个哈希匹配，而不是全部三个吗？
不。但就浏览器的行为而言：如果最强的哈希匹配，则浏览器将使用该哈希，而忽略其余的哈希（因此，其他哈希是否匹配也无所谓）。
据我所知，
- 提供所有三个哈希值而不是仅提供一个哈希值有什么好处吗？
目前没有当前的好处。这是因为根据https://w3c.github.io/webappsec-subresource-integrity/#hash-functions，“合格的用户代理必须支持SHA-256，SHA-384和SHA-512加密哈希函数”。
因此，当前，您只需指定SHA-512哈希即可，所有支持SRI的浏览器都将使用该哈希。
但是，根据https://w3c.github.io/webappsec-subresource-integrity/#agility，指定多个哈希的能力的目的是“面对未来的密码发现提供敏捷性……鼓励作者在可用时开始向更强大的哈希函数迁移”。 / p>
换句话说，在将来的某个时候，浏览器将开始添加对更强大的哈希函数（基于SHA-3的https://en.wikipedia.org/wiki/SHA-3或其他功能）的支持。
因此，由于您将需要继续定位较旧的浏览器和较新的浏览器，因此在一段时间内，您将某些SHA-512作为最强哈希函数的浏览器，同时将到那时出现的新浏览器将增加对某些SHA-3（或其他）哈希函数的支持。
因此，在这种情况下，您需要在integrity值中指定多个哈希。
- 类似于＃1，如果您仅提供一个哈希值，则应使用哪个值？
据我了解，SHA-512值。
我通常会看到网站（例如Bootstrap）在其示例代码中提供sha384值。那是因为它在中间，不是太大，也不是太小？
不知道为什么他们选择那样做。但是，由于要求浏览器支持SHA-512哈希，因此，您不能通过指定SHA-384哈希来获得任何收益-实际上，您只是失去了拥有最强大的哈希功能的价值。
- 出于好奇，可以在
integrity和<script>旁边的任何标签上使用<link>属性。
不，还不能-尚未。
我特别想知道诸如
<img>，<source>等多媒体标签。
SRI的计划始终是最终将其用于那些人。如https://w3c.github.io/webappsec-subresource-integrity/#verification-of-html-document-subresources所述：
注意：此规范的未来修订版可能会包括对所有可能的子资源的完整性支持，例如，
a，audio，embed，iframe，{{ 1}}，img，link，object，script，source和track元素。
...但是我们还没有那个将来。