内容安全策略写法详解:用 CSP 响应头挡住 XSS 注入

跨站脚本(XSS)是网站最常见的攻击面之一。攻击者只要往页面里塞进一段 <script>,浏览器就会照单全收地执行它。内容安全策略(Content Security Policy,简称 CSP)就是为了堵这个洞:它是一条 HTTP 响应头,告诉浏览器允许从哪些来源加载脚本、样式、图片和字体。配对了,即便有注入,代码也跑不起来。

CSP 到底拦的是什么

CSP 的核心思想是白名单。默认情况下浏览器对任何来源的资源都不设防,CSP 把这个逻辑反过来:只有你明确列出的来源才放行,其余一律拒绝。它管的不只是脚本,还包括样式、图片、字体、网络连接(connect-src)、iframe 嵌入(frame-src)、表单提交目标(form-action)等等。

最关键的一条是 default-src 'self'。default-src 是所有 fetch 类指令的兜底,凡是你没单独写的指令都回退到它。设成 'self' 意味着脚本、样式、图片、连接默认只允许同源,也就是协议、主机、端口三者都和当前页面相同。换句话说,跨域脚本不在你的白名单里,就一行都执行不了。我的习惯是先把 default-src 'self' 当地基铺好,再针对个别指令往外放,而不是反过来一条条收紧,后者太容易漏。

一条能直接上线的 CSP 响应头

光说概念太虚,看一条真实的策略:

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.jsdelivr.net; style-src 'self' 'unsafe-inline'; img-src 'self' data:; connect-src 'self' https://api.example.com; frame-ancestors 'none'; base-uri 'self'

逐段拆开看:default-src 'self' 是基线;script-src 额外放行了 jsdelivr 这个 CDN;img-src 允许同源图片加上内联的 data: 图;connect-src 把后端 API 域名加进了白名单;frame-ancestors 'none' 顺手挡掉了点击劫持,不让任何站点把你的页面嵌进 iframe。这一行贴进 Nginx 的 add_header 或服务器配置就能生效。

unsafe-inline 是个陷阱

很多人配 CSP 时会被控制台报错逼疯,于是顺手加上 'unsafe-inline' 把错误消掉。这一步几乎等于把 CSP 关掉。

'unsafe-inline' 会让页面执行内联的 <script> 块和 onclick 这类内联事件处理器,而这恰恰是 XSS 利用的主通道。给 script-src 开了它,被注入的内联脚本照样会跑,你的白名单形同虚设。正确做法是把内联代码挪进独立文件,或者给每次请求发一个随机 nonce('nonce-abc123')或哈希('sha256-...'),只放行你自己写的那几段。style-src 上的 'unsafe-inline' 风险低一些,但内联样式仍可能借 CSS 选择器把数据偷传出去,能避则避。

怎么上线才不把站点搞挂

直接上强制策略,大概率会因为漏掉某个合法来源把页面搞花。稳妥的顺序是先用仅上报模式过渡。

发 Content-Security-Policy-Report-Only 头并配一个 report-to 端点,浏览器会照常加载一切,只把"如果强制会被拦"的情况上报给你。盯一周上报,把每个合法来源补进策略,等上报安静下来,再把头名字换成 Content-Security-Policy 正式强制。这样既不影响线上,又能逐步收敛出一份精确的白名单。

手动维护这些指令容易拼错,我平时直接用 CSP 生成器勾选指令和来源,它会同时吐出响应头、meta 标签和 Nginx 三种写法,还会在你给 script-src 开 'unsafe-inline' 或用裸 https: 通配符时实时弹提示。拼好的策略上线前,再丢进 CSP 策略审计器反向查一遍缺口,比如有没有漏掉 object-src、通配符是不是放得太宽,两者配着用最顺手。

小结

CSP 不是银弹,但它是性价比极高的一道纵深防御。记住三条就够上手:default-src 'self' 当基线、能不开 'unsafe-inline' 就别开、上线先走仅上报。把这条响应头配明白,你的站点对 XSS 的抵抗力会上一个台阶。

Made by Toolora · Updated 2026-06-13