csp是防御xss最有效的机制之一，通过http响应头设置script-src等指令限制脚本来源，禁止内联执行和eval，配合object-src、form-action等指令构建完整防线，即使存在xss漏洞，恶意脚本也无法运行。
Content Security Policy（CSP）是防御XSS最有效的机制之一，它不依赖对输入或输出做字符转义，而是从浏览器加载行为层面切断恶意脚本的执行路径。只要配置得当，即使页面存在XSS漏洞，注入的脚本也无法运行。
核心配置方式：优先用HTTP响应头
推荐在服务端通过HTTP响应头设置CSP策略，这样能覆盖所有资源加载场景，包括HTML文档本身、内联脚本、重定向后的页面等。相比标签，响应头更早生效、无法被前端代码覆盖。
- 使用Content-Security-Policy响应头（非过时的X-Content-Security-Policy）
- 避免使用Content-Security-Policy-Report-Only长期代替强制策略，它只上报不拦截，不能真正防御
- 开发阶段可先启用Report-Only模式观察违规行为，确认无误后再切为强制执行
关键指令与安全写法
必须明确指定script-src，这是防御XSS的核心。默认情况下，浏览器允许内联脚本和eval，这正是XSS常利用的入口。
- 禁止内联脚本：script-src 'self' —— 只允许同源JS文件，自动拦截<script>alert(1)</script>和onclick事件等
- 如需保留少量内联脚本，用nonce机制：script-src 'self' 'nonce-abc123'，并在对应<script nonce="abc123">中添加匹配属性</script>
- 绝对避免'unsafe-inline'和'unsafe-eval'，它们会直接废掉CSP对XSS的防护能力
- 补充基础防护：object-src 'none'禁用Flash/Java插件，base-uri 'self'防止base标签劫持页面解析上下文
配合其他指令构建完整防线
CSP不是只管JS，XSS常借助图片、iframe、样式甚至表单提交完成攻击链，需协同控制。
- img-src 'self' data: —— 允许同源图和data URI，防止恶意图片URL触发JS执行（如onerror）
- connect-src 'self' —— 限制fetch/Ajax目标，阻断XSS后外传敏感数据的行为
- form-action 'self' —— 防止攻击者篡改表单action，诱导用户提交到钓鱼地址
- default-src 'none' + 显式放开各类型 —— 比只设script-src更严格，避免遗漏指令导致宽松回退
上线前必须验证的细节
CSP容易因配置疏漏而失效，尤其在已有复杂前端架构的项目中。
- 检查所有第三方SDK（统计、监控、广告）是否在script-src白名单中，否则功能异常
- 确认Webpack/Vite等构建工具未自动生成内联style或script，必要时配置style-src 'self' 'unsafe-inline'并尽快迁移至外部CSS
- 启用report-uri或report-to接收违规报告，在真实用户环境收集绕过线索
- 用Chrome DevTools的Console和Security面板实时查看CSP违规日志，比仅靠测试用例更可靠
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
