CSP 是什么？

核心解释

CSP 通过 Content-Security-Policy 响应标头下发。正确策略可以显著压缩跨站脚本攻击的利用空间。

CSP 如何把网页资源限制成允许列表

CSP（Content Security Policy）通过响应标头或 meta 元素声明页面允许加载和执行哪些脚本、样式、图片、字体、框架与连接来源。浏览器在执行资源前核对策略，可以压缩注入内容能够利用的范围，尤其适合作为 XSS 的纵深防御。

CSP 不是简单地把所有外部域名列入白名单。现代策略更推荐 nonce 或 hash 授权本次页面的可信脚本，并结合 strict-dynamic 传播信任，减少维护庞大主机列表和被同源可控资源绕过的风险。

关键指令如何控制不同攻击面

• default-src 提供多数资源类型的回退，script-src、style-src、img-src、connect-src 等再对具体类型收紧。
• object-src 'none' 可关闭旧插件内容，base-uri 限制 base 标签，frame-ancestors 控制哪些页面可嵌入当前页面。
• nonce 与 hash 允许特定内联代码，unsafe-inline 会显著放宽脚本或样式限制，是否被 nonce 覆盖取决于具体策略。
• report-to 或 report-uri 可收集违规事件；Report-Only 模式只报告不阻止，适合上线前观察真实依赖。

从报告模式迁移到强制策略

成熟迁移会先盘点第一方与第三方资源，移除不必要脚本，为动态页面生成不可预测 nonce，并在 Report-Only 中观察误报。报告可能包含浏览器扩展、广告与恶意注入噪声，需要按页面模板和资源来源归类。

把大量域名和 unsafe-inline、unsafe-eval 全部加入只为消除报错，会让策略看似存在却缺少实际约束。CSP 应与输出编码、模板安全、依赖更新和 Trusted Types 等代码措施配合，不能代替修复注入根因。

实际应用与信息解读

取得完整策略后，可以分析覆盖的资源类型、nonce/hash、宽泛来源和报告配置。仅看到 Content-Security-Policy 标头不能自动判断强度；同名的 Report-Only 也不代表浏览器已经阻止违规资源。

没有 CSP 表示少了一层浏览器策略，不证明页面存在 XSS。若策略过于宽泛，可以推测其限制能力可能有限，但具体可利用性仍需要结合页面输入与脚本行为。

重点关注

CSP 是纵深防御措施，不能代替输入过滤、输出编码和依赖安全管理。

常见问题

配置 CSP 后就不会有 XSS 吗？

不会。CSP 是纵深防御，仍需正确输出编码、DOM 操作和依赖管理；错误或宽泛策略也可能被绕过。

Report-Only 与正式 CSP 有什么不同？

Report-Only 记录违规但不阻止资源，适合调试；正式 Content-Security-Policy 才会执行限制。

为什么不建议长期使用 unsafe-inline？

它会允许大量内联代码执行，削弱脚本来源约束。nonce 或 hash 通常能更精确授权可信代码。