CSP本身不拖慢XSS防御，但配置错误会让它形同虚设；它是一道零开销的声明式防线，真正风险在于误配unsafe-inline、nonce复用或忽略输入输出编码等基础防护。
HTML CSP本身不拖慢XSS防御，但配置错误会让它形同虚设
CSP（Content Security Policy）不是XSS的“加速器”，也不是“减速带”——它是一道声明式防线，生效速度几乎为零开销。浏览器在解析HTML时同步检查script、eval、内联事件等是否符合策略，不引入额外网络请求或JS执行。真正拖慢防御的，是误用unsafe-inline、过度依赖nonce却漏配、或把CSP当成唯一手段而忽略输入输出编码。
常见错误现象：Refused to execute inline script报错后直接删掉'unsafe-inline'，结果页面白屏；或者加了script-src 'self'却忘了给Vue/React的v-on:click绑定留出空间。
- 内联脚本（如
<button onclick="doIt()"></button>）默认被禁，需显式配unsafe-inline（不推荐）或改用nonce/hash -
eval()、setTimeout("...")、Function("...")全被script-src拦截，现代框架一般不依赖这些，但老项目可能踩坑 -
script-src 'self'不会阻止从https://cdn.example.com/jquery.js加载——必须显式列出可信域名，否则403且无降级逻辑
怎么用nonce安全启用内联脚本而不留后门
nonce是当前最实用的内联脚本放行方式，但它不是“贴个值就完事”。服务端每次响应必须生成**全新、不可预测、单次有效**的base64字符串，并严格同步到HTTP头和HTML标签中。
使用场景：Vue组件里写<script nonce="abc123">initChart()</script>，同时HTTP响应头含Content-Security-Policy: script-src 'nonce-abc123'。
立即学习“前端免费学习笔记（深入）”；
- 千万别硬编码
nonce值（如nonce="static"），这等于开放unsafe-inline - 模板引擎（如EJS、Jinja）要确保
nonce变量在每次请求中重新生成，不能缓存响应体 - 如果用了CDN或反向代理，确认它不缓存含
nonce的HTML——否则多个用户共享同一nonce，攻击者可复用 -
nonce只对<script></script>和<style></style>生效，onclick等内联事件仍被禁，得改用addEventListener
script-src 'strict-dynamic'能简化策略，但别乱用
strict-dynamic让浏览器信任由可信脚本动态创建的子资源（如document.createElement('script')），从而摆脱对域名白名单的强依赖。它适合Webpack打包+入口脚本可信的场景，但对传统多JS文件直引项目反而更难控。
性能影响几乎为零，但兼容性要注意：IE全系不支持，iOS Safari 15.4+才完整支持strict-dynamic与nonce组合。
- 必须搭配
nonce或hash使用，单独写script-src 'strict-dynamic'会被浏览器忽略 - 不能和
'self'或域名并列（如script-src 'self' 'strict-dynamic'），后者会覆盖前者，导致所有外链脚本被拒 - 动态插入的
script若含eval或innerHTML拼接，依然受CSP限制——strict-dynamic不豁免危险API
XSS防御不能只靠CSP，三件套缺一不可
CSP是最后一道网，不是过滤器。它拦不住已注入的恶意HTML被渲染（比如<img src="x" onerror="alert(1)" alt="HTML CSP会拖慢XSS防御吗_HTML CSP结合XSS防御用法【快速上手】" >），除非你配了default-src 'none'再逐项放开——但这基本没法用。
真正起效的组合是：输入侧做白名单过滤（如仅允许字母数字+空格） + 输出侧做上下文编码（HTML/JS/URL三类场景用不同转义） + CSP作为兜底（防漏网的eval、外链劫持、内联滥用）。
容易被忽略的点：JSON接口返回用户可控内容时，如果前端用innerHTML = data.content渲染，CSP拦不住——因为没触发script执行，只是DOM注入。这时候必须靠输出编码或textContent。
