subresource integrity（sri）通过验证外部资源的完整性来提升前端安全性。1. 它防止cdn劫持或篡改，确保从外部加载的资源未被修改；2. 防御供应链攻击，避免因依赖库被植入恶意代码而受影响；3. 减少人为失误带来的风险，如错误版本上传至cdn。sri通过在html标签中添加integrity和crossorigin属性实现，浏览器会比对资源哈希值，不匹配则拒绝加载。虽然sri提升了安全性，但也存在维护成本高、需指定固定版本、错误处理复杂等挑战，需通过自动化流程应对。
HTML5的integrity属性，准确地说，是Subresource Integrity（SRI）的一部分，它的核心作用是为你的网页引入的外部资源（比如CDN上的JavaScript库或CSS样式表）提供一个安全校验机制。简单讲，就是确保你从外部加载进来的文件，在传输过程中没有被恶意篡改过。浏览器会计算下载资源的哈希值，并与你预设的哈希值进行比对，如果不一致，这个资源就会被浏览器拒绝加载，从而大大降低了供应链攻击的风险。
解决方案
要验证资源完整性，你需要在使用或标签引入外部资源时，添加integrity属性和crossorigin属性。integrity属性的值是一个或多个加密哈希值（例如SHA-256、SHA-384、SHA-512），前缀指明了哈希算法，后面跟着该资源的Base64编码哈希值。crossorigin属性是强制性的，它告诉浏览器如何处理跨域请求的凭证，并且是SRI工作的前提。当浏览器下载资源后，它会计算该资源的实际哈希值，然后与integrity属性中提供的哈希值进行比较。如果哈希值不匹配，或者crossorigin属性缺失或设置不当，浏览器就会阻止该资源的执行或应用，并在控制台报错。这就像给你的外部资源加了一把“数字锁”，只有钥匙（正确的哈希值）才能打开。
为什么我们需要Subresource Integrity（SRI）？它解决了哪些安全痛点？
我个人觉得，SRI的出现，简直是现代前端安全的一剂良药。你想想看，我们现在有多少网站离不开CDN？jQuery、React、Vue这些库，哪个不是从CDN加载的？虽然CDN加速了内容分发，提高了用户体验，但它也引入了一个巨大的安全隐患：如果CDN本身被攻破，或者其服务器上的某个资源被恶意篡改了，那所有引用这个资源的网站，都会在不知不觉中执行恶意代码。这可不是危言耸听，历史上类似的攻击并不少见。
立即学习“前端免费学习笔记（深入）”；
SRI解决的正是这种“第三方信任”的痛点。它不再是盲目地信任CDN提供的内容，而是引入了一个“验证”环节。就像你去取包裹，快递员说这是你的，但你还是会检查一下包裹上的信息是不是你的。SRI就是这个“检查”的过程。它防止了以下几种常见的安全风险：
- CDN劫持或篡改： 这是最直接的防护目标。即使CDN服务器被黑客入侵，或者在传输过程中数据被劫持并修改，只要哈希值不匹配，浏览器就不会加载被篡改的资源。
- 供应链攻击： 比如你使用的某个开源库，其官方发布流程中的某个环节被攻破，导致发布的版本被植入了恶意代码。如果你的构建流程集成了SRI哈希的生成和校验，那么这种恶意版本在部署时就能被及时发现。
- 人为失误： 偶尔也会发生，比如不小心上传了错误版本的文件到CDN。SRI也能在一定程度上帮助发现这类问题。
SRI的价值在于，它将安全控制从“信任外部服务”转变为“自我校验”，极大地增强了前端应用的安全性。
如何为你的外部资源生成并应用Integrity哈希值？
生成integrity哈希值，其实并不复杂，但需要你在部署流程中加入一个步骤。最常见的方法是使用命令行工具，比如OpenSSL。假设你有一个名为my-script.js的JavaScript文件，你想生成它的SHA-384哈希值，你可以这样做：
cat my-script.js | openssl dgst -sha384 -binary | openssl base64
这条命令会输出一个Base64编码的字符串，前面加上sha384-前缀，就是你可以直接用在integrity属性里的值。例如，如果输出是abcDEF123...，那么你的integrity值就是sha384-abcDEF123...。
应用到HTML中，示例如下：
对于JavaScript文件：
对于CSS样式表：
crossorigin="anonymous"是必不可少的，它表示在发送跨域请求时，不携带用户凭证（如cookies、HTTP认证证书等）。这不仅是SRI的要求，也是一种安全最佳实践，避免了不必要的凭证泄露。
在实际项目中，特别是大型项目，你不会手动去生成这些哈希值。通常会集成到你的构建工具链中，比如Webpack、Rollup的插件，或者CI/CD流程中的脚本，在每次发布新版本时自动计算并更新这些哈希值。这样才能确保哈希值与资源内容始终保持同步。
Integrity属性的局限性与实施挑战有哪些？
虽然SRI非常强大，但它并非银弹，实施起来也确实存在一些挑战和局限性。这些是我在实际项目中遇到过，或者思考过的点：
维护成本： 这是最直接的挑战。只要你引用的外部资源内容有任何微小改动（哪怕只是一个空格或注释），它的哈希值就会完全改变。这意味着你每次更新CDN上的JS或CSS文件，都必须同时更新HTML中对应的
integrity哈希值。对于频繁更新的库或者组件，手动维护几乎是不可能的，必须依赖自动化构建流程。如果自动化做得不够好，很容易出现哈希不匹配导致资源加载失败的问题。版本管理： 很多CDN会提供不同版本的资源路径，例如
jquery/3.6.0/jquery.min.js。如果你直接引用最新版本（jquery/latest/jquery.min.js），那么integrity属性就失去了意义，因为latest指向的文件内容会随时变化。SRI要求你引用的是一个内容固定不变的资源，这意味着你必须指定具体的版本号。这可能与一些项目追求“始终使用最新版本”的策略相冲突，需要在安全性与便利性之间做权衡。错误处理： 当SRI校验失败时，浏览器会阻止资源加载，并在控制台报错。虽然这是预期行为，但对于终端用户来说，页面功能可能会受损。你需要有完善的监控和日志系统来捕获这些错误，以便及时发现并解决问题。
开发环境的复杂性： 在开发阶段，我们可能经常修改本地文件，或者使用本地代理。这时如果开启了SRI校验，就可能导致资源加载失败，因为本地修改后的文件哈希值与HTML中预设的不符。通常的做法是在开发环境禁用SRI，或者有专门的开发模式来处理。
非CDN资源： SRI主要针对从CDN等第三方源加载的资源。对于同源的资源，或者通过其他方式（如内联脚本）加载的资源，SRI并不适用。
尽管有这些挑战，但我认为SRI带来的安全收益是巨大的，远超其维护成本。只要在项目初期就规划好自动化流程，并理解其工作原理和局限性，SRI绝对是你前端安全策略中不可或缺的一环。它迫使我们对外部依赖保持一种健康的“怀疑”态度，并采取实际行动来验证它们的完整性。
