CSP（Content Security Policy，内容安全策略）是一份由服务器下发的"白名单声明"：告诉浏览器，这个页面只允许加载哪些来源的脚本、样式、图片和框架，名单之外的资源一律拒绝执行或加载。
打个比方。网页是一个小区，XSS（跨站脚本）攻击就是有人伪装成快递员混进小区。输入过滤和输出转义是门口保安，他可能走神，可能被新话术骗过；CSP 是每个单元楼下的门禁，不管你是谁、怎么进来的，不在住户名单上就是打不开门。所以 CSP 不负责"堵住漏洞"，它负责"即使漏洞被利用，也尽量让脚本跑不起来"。
它靠 HTTP 响应头生效，最常见的一行是这样：
```
Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-随机串'; object-src 'none'; base-uri 'self'
```
逐条翻译：默认只信任同源资源；脚本只信任同源文件和带本次随机串（nonce）的标签；禁止插件对象；禁止篡改页面基准地址。这里的 nonce 是服务器每次响应现生成的随机值，写进 <script nonce="..."> 才放行。攻击者注入的内联脚本猜不到这个值，直接被拦下，这正是对抗 XSS 的关键一招。
配置上的几个经验：
- 不要开
'unsafe-inline'。它等于告诉浏览器"内联脚本随便跑"，绝大多数 XSS 就是这么进来的，开了 CSP 基本等于没开。 'strict-dynamic'是新站点的好帮手。配合 nonce 使用后，被信任的脚本再动态插入的脚本也自动信任，省去维护一长串域名白名单的麻烦。- 先上报告模式。用
Content-Security-Policy-Report-Only头只上报违规、不拦截，跑一段时间看看会误伤哪些资源，调整完再切成强制模式。 - 别忘了收尾。
object-src 'none'、base-uri 'self'、frame-ancestors这几条成本极低，收益稳定。
CSP 容易和几个邻居混在一起，区别如下：
| 机制 | 管什么 | 和 CSP 的关系 |
|---|---|---|
| CORS | 别的站点能不能读我的响应 | 方向相反，CSP 管我加载谁 |
| SRI（子资源完整性） | 单个文件哈希是否被篡改 | 互补，一个管文件真伪，一个管来源名单 |
| X-XSS-Protection | 浏览器内置的反射型 XSS 过滤器 | 已废弃，现代浏览器不再依赖它 |
| 输入过滤 / 输出转义 | 从源头阻止恶意内容进入页面 | 必做，CSP 是它失手后的兜底 |
对普通职场人来说，记住一句话就够：CSP 不是"防黑客"，而是"给已经混进来的坏人加一道门禁"。
对做 AI 应用的人则更实际。把大模型的输出渲染到网页时，很多人图省事直接把它塞进 innerHTML，而模型输出是可控性最差的文本——用户一句提示词就可能诱导它吐出带事件属性的标签。这类场景里，严格 CSP 往往是最便宜、也最有效的一层保险。具体指令和浏览器支持情况，以 MDN 等官方页面为准。