打开手机银行App时，你有没有想过，为什么页面加载的内容不会被恶意替换？这背后可能就藏着SRI和CSP这两项技术的配合。它们就像两位保安，一个检查进门的人是否身份真实，另一个规定谁能进哪扇门。
什么是SRI和CSP？
SRI（Subresource Integrity）的作用是验证网页加载的外部资源，比如从CDN下载的JavaScript文件，有没有被篡改。它通过比对资源的哈希值来确认完整性。比如你在用某款记账App时，它引用了一个外部图表库，SRI能确保这个库没被替换成偷数据的假版本。
CSP（Content Security Policy）则是设定内容加载的规则。它可以告诉浏览器：“只允许运行来自自己服务器的脚本，禁止内联脚本。”这样一来，即使攻击者在页面中注入了恶意代码，CSP也能直接拦下。
单独用不够稳
只靠SRI，虽然能校验资源完整性，但如果攻击者通过其他方式插入新的脚本标签，SRI管不着。而只设CSP，虽然限制了来源，但万一合法CDN被劫持，加载了带毒脚本，CSP也可能放行。这就像是防盗门装得好，但钥匙被人复制了，还是有风险。
联手才够硬气
当SRI和CSP一起上阵，防护就立体了。CSP先划定可加载资源的白名单，SRI再对每个资源做指纹核验。两者叠加，既控制来源又验证内容。
比如一个手机购物App，在HTML中这样写：
<script src="https://cdn.example.com/jquery.js" integrity="sha384-abc123..." crossorigin="anonymous"></script>同时在HTTP头中设置：
Content-Security-Policy: script-src 'self' https://cdn.example.com; object-src 'none';这样一来，只有来自指定域名的脚本才能加载，而且必须通过哈希校验。哪怕CDN出问题，或者有人伪造链接，双重关卡也能挡住大部分攻击。
现在很多主流App的内嵌网页都在悄悄用这套组合拳。你平时刷的电商详情页、在线缴费界面，背后可能都有SRI+CSP在撑着。它们不显山露水，却实实在在防住了不少“中间人篡改”和“XSS攻击”。
对于开发者来说，加几行配置就能提升安全水位，何乐不为？对用户而言，虽然看不见这些代码，但每一次安心点击支付，都是技术在默默护航。