网站加载第三方脚本时，如果CDN被黑或资源遭中间人篡改，攻击者就能注入恶意代码，直接盗取用户数据或控制页面行为。要彻底堵住这个漏洞，必须同时启用SRI（子资源完整性校验）和CSP（内容安全策略），两者缺一不可——SRI确保单个脚本文件内容未被篡改，CSP则全局监控并阻止任何未经授权的脚本执行。

一、SRI：为每个第三方脚本加上“数字指纹”锁

SRI的工作原理很简单：网站管理员在引入外部脚本或样式表时，通过integrity属性附加该文件的哈希值。浏览器下载文件后会重新计算哈希，若与预设值不匹配，则立即阻断加载。这意味着即使攻击者替换了CDN上的文件，也无法在用户端生效。

具体实施时，你需要使用openssl或在线工具生成资源的SHA256、SHA384或SHA512哈希值，并将其插入link或script标签：

<script 
  src="https://cdn.example.com/vue.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
  crossorigin="anonymous">
</script>

注意必须同时配置crossorigin="anonymous"，否则浏览器会因CORS限制跳过校验。但SRI有局限：它只能保护明确标注integrity的资源，若页面被注入新的恶意脚本标签，SRI无法拦截。

二、CSP：设立全局脚本“白名单”防线

CSP通过HTTP响应头或meta标签定义资源加载规则，从根本上限制脚本执行来源。一个典型的防御第三方篡改的CSP策略应包含：

Content-Security-Policy: 
  default-src 'self'; 
  script-src 'self' https://trusted.cdn.com 'sha256-xxx'; 
  style-src 'self' 'unsafe-inline'; 
  object-src 'none';

其中script-src指令最为关键：'self'只允许同域脚本，https://trusted.cdn.com限定特定第三方CDN，而'sha256-xxx'支持内联脚本哈希白名单。强烈建议添加object-src 'none'以封锁Flash等插件攻击向量。

启用CSP后，即使攻击者成功注入<script src="http://malicious.com/evil.js"></script>，浏览器也会因域名不在白名单而拒绝加载。但CSP无法验证白名单内资源内容是否被篡改——这正是需要结合SRI的原因。

三、SRI+CSP联合防御实战部署步骤

1. 审计所有第三方资源：使用安全扫描工具列出所有外部脚本、样式表、字体及媒体文件，评估其必要性并记录当前版本。

2. 分阶段实施SRI：首先为核心支付、登录验证等关键脚本添加integrity属性。建议同时提供多个哈希算法备用（如sha384+sha512），防止单一算法被攻破。注意版本更新时必须同步更新哈希值。

3. 配置渐进式CSP策略：初期采用Content-Security-Policy-Report-Only模式，仅收集违规报告而不实际拦截。分析报告后逐步收紧策略，最终移除'unsafe-inline'和'unsafe-eval'等宽松选项。

4. 建立监控告警机制：通过CSP报告端点或SIEM系统收集违规日志，设置异常请求阈值告警。例如同一页面突然出现大量未授权资源请求，很可能是正在发生的攻击。

四、应对动态加载脚本的进阶方案

现代网站常通过JavaScript动态创建script标签加载资源。此时需在CSP中启用strict-dynamic特性：

script-src 'strict-dynamic' 'nonce-abc123' 'sha256-xxx';

strict-dynamic允许受信任脚本加载下级资源，配合一次性随机数（nonce）或哈希值使用。但注意nonce需服务器动态生成，避免静态值被攻击者破解。

对于Webpack等打包工具生成的资源，可启用Subresource Integrity插件自动为所有chunk文件注入哈希。同时建议在nginx/apache层设置CSP头部，避免前端HTML被篡改绕过策略。

五、必须规避的常见配置误区

误区1：在CSP中过度使用'unsafe-inline'。这会使内联脚本攻击完全失效，应改用nonce或哈希机制替代。

误区2：忽略预加载资源的校验。使用<link rel="preload">时需额外添加crossorigin和integrity属性，否则可能加载篡改后的缓存版本。

误区3：未设置备用哈希算法。当CDN服务器升级导致资源轻微变更（如添加注释），单一哈希失败会直接阻断加载。建议生产环境同时提供sha384和sha512双哈希值。

误区4：忘记监控CSP报告。没有持续分析违规报告，可能遗漏策略配置错误或早期攻击迹象。应建立自动化仪表盘跟踪关键指标。

六、面向未来的完整性保护趋势

随着Web组件和模块化发展，新的安全标准正在完善。Signed HTTP Exchanges（SXG）允许对整站资源进行数字签名，配合SRI可实现端到端验证。浏览器厂商也在推动Require-SRI-For头提案，强制指定类型资源必须通过完整性校验。

建议开发团队将SRI/CSP检查纳入CI/CD流水线，在代码合并前自动验证资源哈希与策略合规性。同时考虑采用TUF（The Update Framework）等供应链安全框架，从源头保障第三方库更新过程不受篡改。

最终，真正的安全防御需要分层实施：SRI作为资源完整性“检查点”，CSP作为执行环境“守卫者”，再配合HTTPS强制传输、子资源TLS证书绑定等机制，才能构建对抗第三方脚本篡改的纵深防御体系。