2026/8/17 15:53:00
FEATURED · 精选文章 
webappsec SRI polyfill 原理剖析旧浏览器也能做子资源完整性校验【免费下载链接】webappsecWeb Application Security Working Group repo项目地址: https://gitcode.com/gh_mirrors/we/webappsec子资源完整性校验SRISubresource Integrity是 Web 安全领域一项至关重要的能力它让浏览器在加载脚本、样式表之前先核对文件的哈希值防止 CDN 或第三方服务器被攻破后向页面注入恶意代码。本文为你深度剖析 webappsec 项目中的 SRI polyfill 实现原理并回答一个关键问题当老旧的浏览器不支持 SRI 时我们如何用 polyfill 补齐这道安全防线什么是子资源完整性校验SRI为什么它如此重要现代网页几乎不可能只依赖自家服务器。jQuery、统计脚本、字体、样式框架……大量资源托管在 CDN 或第三方平台上。这些资源带来速度优势的同时也引入一个致命风险你无法保证 CDN 返回的文件真的是你当初放上去的那一份。攻击者可以通过 DNS 投毒、劫持 CDN 服务器、供应链攻击等方式悄悄替换远端文件。而 HTTPS 只能证明你连上了对的服务器无法证明服务器返回了对的资源。SRI 的出现正是为了解决内容被篡改这一层风险——它把安全信任从服务器下沉到内容本身。webappsecWeb Application Security Working Group是 W3C 负责制定这一系列 Web 安全规范的工作组仓库SRI 规范正是其核心成果之一你可以在 specs/subresourceintegrity/spec.markdown 看到完整算法描述。SRI 工作原理速览integrity 属性、哈希与 base64SRI 的用法非常简单直观。开发者先在本地计算出资源文件的哈希值再把哈希写进标签的integrity属性script srchttps://cdn.example.com/lib.js integritysha384-Li9vy3DqF8tnTXuiaAJuML3kyer10rcgNR/VqsVpcwThHmYcwiB1pbOxEbzJr7 crossoriginanonymous/script浏览器加载资源后会做三件事解析元数据从integrity属性中读出算法名如sha384和 base64 编码的摘要值本地计算摘要对实际收到的文件内容运行同样的哈希算法比对结果一致则正常执行不一致则拒绝执行并上报错误。规范要求浏览器必须支持 SHA-256、SHA-384、SHA-512 三种算法。这里有两个新手最容易踩的坑跨域资源必须开启 CORScrossoriginanonymous不能省略否则浏览器出于防止暴力猜测的安全考虑会直接判定资源不具备校验资格SRI 形同虚设哈希值是 base64 编码的二进制摘要不是十六进制字符串用openssl dgst -sha384 -binary | openssl enc -base64 -A这类命令生成才正确。规范中校验资格eligible判断、选择最强哈希getPrioritizedHashFunction等细节在 spec.markdown 的 Framework 章节 中有逐条定义值得精读。为什么需要 SRI polyfill旧浏览器的兼容困局SRI 早在 2015 年前后就进入 W3C 规范流程但完整落地到所有浏览器经历了漫长周期。企业内网、老旧系统、嵌入式 WebView、国产浏览器套壳内核……大量环境至今不识别integrity属性。更麻烦的是浏览器不识别integrity时会直接把它当普通属性忽略资源照常加载。这意味着在旧浏览器上你以为开启了 SRI 防护实际完全裸奔——安全防护在无声无息中失效这是最危险的状态。SRI polyfill 存在的意义就是把内容校验这件事从浏览器内核手里接过来用 JavaScript 在页面层模拟实现。SRI polyfill 原理剖析一步步拆解实现思路在 webappsec 仓库中polyfill 的占位文件位于 polyfills/subresourceintegrity/sri-v1.polyfill.js。下面我们剖析一个完整 SRI polyfill 应当具备的核心环节。第一步能力检测判断是否需要接管polyfill 启动后首先要探测当前环境是否原生支持 SRI。常见做法是创建一个带integrity属性的测试脚本元素检查浏览器是否暴露了相关的属性处理痕迹更稳妥的方式是检测crypto.subtleWebCrypto API是否可用——它是 polyfill 计算哈希的唯一现代手段。若浏览器原生支持polyfill 立即收手避免重复校验若crypto.subtle都不可用则只能降级或给出警告。第二步拦截脚本加载建立把关通道这是 polyfill 最精巧也最棘手的地方。浏览器解析 HTML 时遇到带integrity的script标签会立刻开始下载并执行polyfill 必须在执行之前完成校验因此常用的拦截手段有三种改写document.createElement(script)重写工厂方法捕获所有动态创建的脚本元素记录其integrity和crossorigin属性MutationObserver 观察 DOM监听新增的script/link节点弥补静态 HTML 解析阶段的漏网之鱼配合onload/onerror兜底对于已经触发的加载事件先暂存资源内容校验通过后才真正注入执行。第三步计算并比对哈希拦截到目标资源后polyfill 用fetch重新获取资源内容这一步要求服务器正确返回 CORS 头然后调用crypto.subtle.digest(SHA-384, buffer)计算摘要再转换为 base64 与integrity属性中的期望值逐一比对。规范要求实现多哈希取最强逻辑——当属性里同时列出sha384和sha512时应按优先级选择更安全的算法参与比对。第四步校验结果分流比对通过把资源内容原样注入执行比对失败阻断执行、在控制台输出清晰错误SRI 规范的核心目标之一就是失败要可报告。一个成熟的 polyfill 还应暴露回调钩子让站点可以把校验失败事件上报给监控系统。局限polyfill 做不到的事坦诚地说polyfill 有天然的边界静态标签难以完全拦截HTML 解析器可能先于 MutationObserver 触发下载无法 100% 杜绝先执行后校验的窗口性能开销二次 fetch 等于双倍网络请求大资源场景下成本明显依赖 CORS资源服务器不返回Access-Control-Allow-Origin时polyfill 无法读取内容校验无从谈起。所以 SRI polyfill 是过渡期的补丁而非终极方案生产环境仍应推动浏览器升级到原生支持。普通用户/开发者如何快速用上 SRI 校验即使不是安全专家按下面三步也能立刻上手更多细节可参考 SRI 规范的 README生成哈希下载目标文件后执行echo -n $(cat file.js) | openssl dgst -sha384 -binary | openssl enc -base64 -A拼接属性把输出拼成sha384-base64值填进integrity别忘 CORS给script/link加上crossoriginanonymous并确认服务器返回了允许跨域的响应头。对于重定向场景要格外小心——资源经过多次跳转后最终交付的内容可能与预期不一致。下图展示了重定向链路可能引发的加载异常这类场景正是 SRI 校验最容易误伤正常用户的地方上线前务必用真实环境验证常见问题 FAQQ1polyfill 和原生 SRI 会冲突吗优秀的 polyfill 会先做能力检测原生支持时自动让位不会双重校验。Q2为什么跨域脚本必须配crossorigin这是 SRI 规范的强制要求——若没有 CORS 授权任何站点都能拿任意 URL 做哈希猜测等于把跨域内容钓出来违背了防暴破的设计初衷。Q3哈希算法应该选哪个推荐 SHA-384 起步敏感场景用 SHA-512。规范同时鼓励多哈希并列将来某算法被攻破时可平滑切换这个敏捷性设计在 spec.markdown 的 Agility 小节 有专门说明。Q4如何获取 webappsec 仓库代码执行git clone https://gitcode.com/gh_mirrors/we/webappsec即可规范源码、polyfill 占位、历史草稿如 20140318 早期版本都在里面。总结SRI polyfill 的本质是把内容指纹校验从浏览器内核搬进 JavaScript 运行时能力检测确认环境、拦截机制捕获资源、WebCrypto 计算摘要、通过后才放行执行。它让不支持 SRI 的旧浏览器也能获得子资源完整性校验的防护是兼容过渡期的务实之选。但请记住polyfill 只是补丁推动浏览器升级、坚持 CORS 规范、把校验失败纳入监控才是 SRI 安全防线真正稳固的长久之计。webappsec 仓库作为这一整套 Web 安全规范的孵化地值得每一位关注前端安全的开发者持续关注。【免费下载链接】webappsecWeb Application Security Working Group repo项目地址: https://gitcode.com/gh_mirrors/we/webappsec创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
webappsec SRI polyfill 原理剖析：旧浏览器也能做子资源完整性校验
webappsec SRI polyfill 原理剖析旧浏览器也能做子资源完整性校验【免费下载链接】webappsecWeb Application Security Working Group repo项目地址: https://gitcode.com/gh_mirrors/we/webappsec子资源完整性校验SRISubresource Integrity是 Web 安全领域一项至关重要的能力它让浏览器在加载脚本、样式表之前先核对文件的哈希值防止 CDN 或第三方服务器被攻破后向页面注入恶意代码。本文为你深度剖析 webappsec 项目中的 SRI polyfill 实现原理并回答一个关键问题当老旧的浏览器不支持 SRI 时我们如何用 polyfill 补齐这道安全防线什么是子资源完整性校验SRI为什么它如此重要现代网页几乎不可能只依赖自家服务器。jQuery、统计脚本、字体、样式框架……大量资源托管在 CDN 或第三方平台上。这些资源带来速度优势的同时也引入一个致命风险你无法保证 CDN 返回的文件真的是你当初放上去的那一份。攻击者可以通过 DNS 投毒、劫持 CDN 服务器、供应链攻击等方式悄悄替换远端文件。而 HTTPS 只能证明你连上了对的服务器无法证明服务器返回了对的资源。SRI 的出现正是为了解决内容被篡改这一层风险——它把安全信任从服务器下沉到内容本身。webappsecWeb Application Security Working Group是 W3C 负责制定这一系列 Web 安全规范的工作组仓库SRI 规范正是其核心成果之一你可以在 specs/subresourceintegrity/spec.markdown 看到完整算法描述。SRI 工作原理速览integrity 属性、哈希与 base64SRI 的用法非常简单直观。开发者先在本地计算出资源文件的哈希值再把哈希写进标签的integrity属性script srchttps://cdn.example.com/lib.js integritysha384-Li9vy3DqF8tnTXuiaAJuML3kyer10rcgNR/VqsVpcwThHmYcwiB1pbOxEbzJr7 crossoriginanonymous/script浏览器加载资源后会做三件事解析元数据从integrity属性中读出算法名如sha384和 base64 编码的摘要值本地计算摘要对实际收到的文件内容运行同样的哈希算法比对结果一致则正常执行不一致则拒绝执行并上报错误。规范要求浏览器必须支持 SHA-256、SHA-384、SHA-512 三种算法。这里有两个新手最容易踩的坑跨域资源必须开启 CORScrossoriginanonymous不能省略否则浏览器出于防止暴力猜测的安全考虑会直接判定资源不具备校验资格SRI 形同虚设哈希值是 base64 编码的二进制摘要不是十六进制字符串用openssl dgst -sha384 -binary | openssl enc -base64 -A这类命令生成才正确。规范中校验资格eligible判断、选择最强哈希getPrioritizedHashFunction等细节在 spec.markdown 的 Framework 章节 中有逐条定义值得精读。为什么需要 SRI polyfill旧浏览器的兼容困局SRI 早在 2015 年前后就进入 W3C 规范流程但完整落地到所有浏览器经历了漫长周期。企业内网、老旧系统、嵌入式 WebView、国产浏览器套壳内核……大量环境至今不识别integrity属性。更麻烦的是浏览器不识别integrity时会直接把它当普通属性忽略资源照常加载。这意味着在旧浏览器上你以为开启了 SRI 防护实际完全裸奔——安全防护在无声无息中失效这是最危险的状态。SRI polyfill 存在的意义就是把内容校验这件事从浏览器内核手里接过来用 JavaScript 在页面层模拟实现。SRI polyfill 原理剖析一步步拆解实现思路在 webappsec 仓库中polyfill 的占位文件位于 polyfills/subresourceintegrity/sri-v1.polyfill.js。下面我们剖析一个完整 SRI polyfill 应当具备的核心环节。第一步能力检测判断是否需要接管polyfill 启动后首先要探测当前环境是否原生支持 SRI。常见做法是创建一个带integrity属性的测试脚本元素检查浏览器是否暴露了相关的属性处理痕迹更稳妥的方式是检测crypto.subtleWebCrypto API是否可用——它是 polyfill 计算哈希的唯一现代手段。若浏览器原生支持polyfill 立即收手避免重复校验若crypto.subtle都不可用则只能降级或给出警告。第二步拦截脚本加载建立把关通道这是 polyfill 最精巧也最棘手的地方。浏览器解析 HTML 时遇到带integrity的script标签会立刻开始下载并执行polyfill 必须在执行之前完成校验因此常用的拦截手段有三种改写document.createElement(script)重写工厂方法捕获所有动态创建的脚本元素记录其integrity和crossorigin属性MutationObserver 观察 DOM监听新增的script/link节点弥补静态 HTML 解析阶段的漏网之鱼配合onload/onerror兜底对于已经触发的加载事件先暂存资源内容校验通过后才真正注入执行。第三步计算并比对哈希拦截到目标资源后polyfill 用fetch重新获取资源内容这一步要求服务器正确返回 CORS 头然后调用crypto.subtle.digest(SHA-384, buffer)计算摘要再转换为 base64 与integrity属性中的期望值逐一比对。规范要求实现多哈希取最强逻辑——当属性里同时列出sha384和sha512时应按优先级选择更安全的算法参与比对。第四步校验结果分流比对通过把资源内容原样注入执行比对失败阻断执行、在控制台输出清晰错误SRI 规范的核心目标之一就是失败要可报告。一个成熟的 polyfill 还应暴露回调钩子让站点可以把校验失败事件上报给监控系统。局限polyfill 做不到的事坦诚地说polyfill 有天然的边界静态标签难以完全拦截HTML 解析器可能先于 MutationObserver 触发下载无法 100% 杜绝先执行后校验的窗口性能开销二次 fetch 等于双倍网络请求大资源场景下成本明显依赖 CORS资源服务器不返回Access-Control-Allow-Origin时polyfill 无法读取内容校验无从谈起。所以 SRI polyfill 是过渡期的补丁而非终极方案生产环境仍应推动浏览器升级到原生支持。普通用户/开发者如何快速用上 SRI 校验即使不是安全专家按下面三步也能立刻上手更多细节可参考 SRI 规范的 README生成哈希下载目标文件后执行echo -n $(cat file.js) | openssl dgst -sha384 -binary | openssl enc -base64 -A拼接属性把输出拼成sha384-base64值填进integrity别忘 CORS给script/link加上crossoriginanonymous并确认服务器返回了允许跨域的响应头。对于重定向场景要格外小心——资源经过多次跳转后最终交付的内容可能与预期不一致。下图展示了重定向链路可能引发的加载异常这类场景正是 SRI 校验最容易误伤正常用户的地方上线前务必用真实环境验证常见问题 FAQQ1polyfill 和原生 SRI 会冲突吗优秀的 polyfill 会先做能力检测原生支持时自动让位不会双重校验。Q2为什么跨域脚本必须配crossorigin这是 SRI 规范的强制要求——若没有 CORS 授权任何站点都能拿任意 URL 做哈希猜测等于把跨域内容钓出来违背了防暴破的设计初衷。Q3哈希算法应该选哪个推荐 SHA-384 起步敏感场景用 SHA-512。规范同时鼓励多哈希并列将来某算法被攻破时可平滑切换这个敏捷性设计在 spec.markdown 的 Agility 小节 有专门说明。Q4如何获取 webappsec 仓库代码执行git clone https://gitcode.com/gh_mirrors/we/webappsec即可规范源码、polyfill 占位、历史草稿如 20140318 早期版本都在里面。总结SRI polyfill 的本质是把内容指纹校验从浏览器内核搬进 JavaScript 运行时能力检测确认环境、拦截机制捕获资源、WebCrypto 计算摘要、通过后才放行执行。它让不支持 SRI 的旧浏览器也能获得子资源完整性校验的防护是兼容过渡期的务实之选。但请记住polyfill 只是补丁推动浏览器升级、坚持 CORS 规范、把校验失败纳入监控才是 SRI 安全防线真正稳固的长久之计。webappsec 仓库作为这一整套 Web 安全规范的孵化地值得每一位关注前端安全的开发者持续关注。【免费下载链接】webappsecWeb Application Security Working Group repo项目地址: https://gitcode.com/gh_mirrors/we/webappsec创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
