CSP安全策略配置实战：前端XSS防护与常见陷阱解析

脚本专家

CSP（Content Security Policy）是一个通过HTTP响应头实现的安全机制，用于定义浏览器可以加载资源的白名单，从而有效防御XSS、数据窃取、资源注入等攻击。本文将围绕CSP的核心概念、常用指令、实战案例以及调试技巧展开，帮助开发者正确配置并避免常见陷阱。

一、CSP的工作机制
CSP在资源加载前即执行预拦截检查。当浏览器解析到页面需要加载脚本、样式、图片或发起网络请求时，会先比对已解析的CSP规则，若来源不在允许列表中则直接拒绝，不会发起网络请求。这种机制既能防止恶意下载，又能节省带宽。

二、核心指令详解
1. default-src：默认规则，未指定具体类型时使用。例如 default-src 'self' 表示仅允许同源资源。
2. script-src：控制脚本来源，常见用法：script-src 'self' 'unsafe-inline' https://cdn.example.com。其中 'unsafe-inline' 会允许 <script>alert('test')</script> 此类内联脚本，但会降低安全性，生产环境建议使用nonce或hash代替。
3. img-src：控制图片来源，例如 img-src 'self' data: https: blob:，其中 data: 允许Base64编码图片，blob: 允许Blob URL。
4. connect-src：控制AJAX、WebSocket等连接，例如 connect-src 'self' https: wss:。
5. style-src：控制CSS样式来源，支持类似 'unsafe-inline' 等值。
6. font-src、frame-src、media-src 分别对应字体、iframe、音视频资源。

注意：同源检查包括协议、域名、端口三者一致，例如当前页面为 https://www.example.com:443 ，则 http://www.example.com 或 https://api.example.com 均会被拒绝。

三、实战：用户上传图片并预览
场景：用户上传头像，需要在页面上即时预览。此时需考虑CSP对 img-src 的限制。

方法一：使用Blob URL（可能触发CSP问题）

2. const file = event.target.files[0];
3. const blobUrl = URL.createObjectURL(file);
4. const img = new Image();
5. img.src = blobUrl; // CSP检查 img-src 是否允许 blob:

复制代码

若CSP未包含 blob:，则图片加载失败。即使配置了 blob:，不同浏览器对Blob URL的检查严格程度也可能不一致，且需手动释放内存：URL.revokeObjectURL(blobUrl)。

方法二：使用Data URL（推荐）

2. const file = event.target.files[0];
3. const reader = new FileReader();
4. reader.readAsDataURL(file);
5. reader.onload = function(e) {
6.     const dataUrl = e.target.result;
7.     const img = new Image();
8.     img.src = dataUrl; // CSP检查 img-src 是否允许 data:
9. };

复制代码

Data URL将文件内容直接编码为Base64字符串，无需网络请求，CSP支持稳定且跨浏览器一致，推荐用于小图片预览。注意：Data URL会增加页面体积，仅适用于预览场景。

四、常见陷阱与解决方案
1. CSP阻止了浏览器扩展或调试工具。错误信息如：“blocked the loading of a resource at chrome-extension://xxx”。开发环境可临时放宽 script-src 加入 'unsafe-eval'。
2. 外部CDN被阻止。例如使用Vue CDN时需在 script-src 中加入 https://cdn.jsdelivr.net。
3. 动态加载图片失败。若图片来源不在 img-src 白名单中，可改用Data URL或明确添加域名。

五、调试CSP问题
浏览器控制台会直接输出违规信息，例如：“Content Security Policy: The page's settings blocked the loading of a resource at https://example.com/script.js ("script-src").”

推荐使用“Report-Only”模式进行测试，该模式下不会实际阻止资源，仅收集违规报告：
Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self'; report-uri https://example.com/csp-report

线上生产环境建议逐步收紧规则：先设置宽松策略，观察报告中的违规情况，再逐步缩小白名单。

六、安全性与实用性的平衡
最严格策略：仅允许 'self'，适用于内容简单、无外部资源的页面。多数场景需允许已知CDN，酌情使用 data: 而非 blob:。避免使用 'unsafe-inline'，可改用nonce或hash安全替代。

CSP的核心原则是“最小权限”，宁可多配置几个可信域名，也不要为了图省事关闭CSP。合理配置后，能有效抵御大部分常见前端攻击。

热心网友5

楼主写得非常详细，实战部分也很有参考价值。之前调试 Blob URL 踩过坑，后来老老实实用了 data: 方案，确实稳定很多。关于 nonce 和 hash 替代 unsafe-inline 这块，希望楼主能再展开讲讲实际配置时的例子，比如动态脚本注入时怎么配合后端生成 nonce。感谢分享！