What is CSP （内容安全策略）?

正在检查是否收录...

它是如何保证安全的？
- 如何实施 CSP？
安全测试者如何绕过 CSP？
只能辅助，不可做主力

内容安全策略（CSP）

内容安全策略（Content Security Policy, CSP）是一个额外的安全层，用于帮助检测和缓解某些类型的攻击，包括跨站脚本（XSS）和数据注入攻击。

你可以把它看作是一个

白名单制度

。你作为网站的管理员，服务器会返回一个

特殊的 HTTP 头

（Content-Security-Policy）给浏览器：“这个网站只被允许执行来自以下来源的脚本、加载以下来源的图片、连接以下来源的服务器……”，浏览器就会严格遵守这个规定，拒绝任何不在白名单上的内容。

What is CSP （内容安全策略）?

简而言之：服务器给浏览器一份关于安全的声明，浏览器会按照声明来执行。

它是如何保证安全的？

传统的 XSS 防御（如我们上面代码中的转义和过滤）是服务端的，思路是“我把用户输入里的恶意代码清理掉，再输出给浏览器”。但这种方法可能存在漏洞，比如过滤规则被绕过。

CSP 的防御思路是客户端（浏览器端）的，它从根本上改变了浏览器的行为：

阻断内联脚本和样式：
大多数 XSS 攻击都依赖于将恶意代码（如 < script >alert('xss') </script > 或 < img onerror="恶意代码" >) 直接注入到 HTML 页面中。CSP 默认禁止执行所有内联 JavaScript（包括 < script > 块和 HTML 事件处理程序如 onclick）和样式，除非你显式地允许它们（使用 'unsafe-inline' 或 nonce），这极大地增加了攻击难度。
限制资源加载的来源：
即使攻击者成功注入了标签，比如 < script src="https://www.cnblogs.com/mysticbinary/p/https://evil.com/hack.js" >，浏览器在收到 CSP 指令后，会检查 src 中的域名 evil.com 是否在脚本加载的白名单中。如果不在，浏览器根本就不会去请求和加载这个恶意脚本。
禁止使用 eval() 等危险函数：
CSP 默认会禁止使用像 eval()、setTimeout(string)、new Function(string) 这类可以执行字符串形式代码的危险函数，因为它们经常被攻击者利用。

如何实施 CSP？

通常通过在 Web 服务器的 HTTP 响应头中添加 Content-Security-Policy 字段来实现。字段里需要配置通过一系列指令来定义策略，具体指令自己需要再查询吧。

示例 1：一个严格且推荐的策略

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.jsdelivr.net; # 只允许同源和指定的 CDN 的脚本 style-src 'self' 'unsafe-inline'; # 允许内联样式（常见于框架） img-src 'self' data:; # 允许同源和 data:URI 的图片 object-src 'none'; # 完全禁止插件 report-uri /api/csp-report; # 发生违规时向这个地址报告

安全测试者如何绕过 CSP？

虽然 CSP 很强大，但配置不当的 CSP 仍然可能被绕过。安全测试者会检查：

过于宽松的策略：
如果策略中包含 'unsafe-inline' 或 'unsafe-eval'，或者白名单 (*)，那么 CSP 提供的保护就大打折扣。
unsafe-inline——允许旧代码或框架中的内联脚本/样式。unsafe-eval——允许eval函数。
允许 data: URI：
如果 script-src 包含了 data:，攻击者可以注入 <script src="data:text/javascript,恶意代码" > </script >。
允许通配符 *：
过于宽泛的来源。
JSONP 回调函数callback的利用：

若CSP依赖域名白名单（如 script-src https://trusted.com ），攻击者可能通过以下方式绕过：
利用可信域名的JSONP接口注入恶意回调函数（如 https://trusted.com/api?callback=alert(1);// ）
浏览器将收到服务器按照JSONP的规则，返回内容：
```
alert(document.domain);//{"data": "some data from trusted.com Server"}; 
```
AngularJS 等框架的绕过：
在特定版本的 AngularJS 中，即使禁止了 unsafe-eval，也有其他方式可以执行代码。
CSP 注入：
如果页面本身允许用户输入某些内容并反射到 CSP 头中（极其罕见但确实存在），攻击者可能会注入一些指令来修改策略。

只能辅助，不可做主力

CSP无法替代输入过滤；
若开发者完全依赖CSP而忽略输入验证（如未转义用户输入），攻击者仍可能通过DOM型XSS或绕过CSP的其他方式（如滥用JSONP接口）发起攻击。
CSP只是作为纵深防御层；
1. 第一层防御：输入过滤与输出编码（如转义 < 为 \<）；
2. 第二层防御：CSP限制脚本执行条件；
3. 第三层防御：HttpOnly Cookie、CORS策略等。
在使用前，需要做严格的测试，有些前端框架并不能很好兼容CSP；