XSS防护中如何验证输出编码是否生效?

输出编码"已配置"与"已生效"是两回事。模板引擎开启了自动转义、框架声明默认安全，都不等于每一个输出点都按所属上下文正确编码。验证的核心思路是：构造可控输入，观察它在响应中的最终形态，用证据而非印象下结论。

按上下文分别验证

HTML、属性、URL、JavaScript 四种上下文的编码规则不同，验证也必须分开进行。向搜索词、昵称、评论等可控输入点提交包含尖括号、引号、事件属性和 javascript: 链接的测试字符串，然后检查响应源码：HTML 正文中的尖括号应被转义为实体，属性值中的引号应被正确处理，URL 中的数据应被百分号编码，进入 JavaScript 的内容应始终被当作字符串而非可执行代码。这里的关键是查看原始响应源码，而不是只看渲染后的页面——浏览器的自动纠错会掩盖编码缺陷，源码中的字符形态才是可靠证据。

覆盖所有输出路径

同一数据往往有多个输出点：前台页面、后台预览、搜索摘要、文件名展示。只验证前台而忽略后台预览是最常见的盲区，后台用户同样可能触发存储型脚本。富文本场景要额外确认白名单是否拦住了事件属性和伪协议链接，而不能只测 script 标签。凡能提交测试数据的地方就用测试账号实际提交，能从日志确认的就不要只凭页面表现判断。

避免两类误判

一是把"没弹窗"当成"编码生效"。弹窗是否出现受浏览器差异和 CSP 拦截影响，脚本未执行不代表输出已正确编码；CSP 只是兜底防线，不能替代编码验证本身。二是把单次验证当成永久结论。模板改动、富文本规则调整、新增输出点都可能让已验证的编码失效，因此验证用例应固化进回归清单，每次相关变更后重跑，并将测试字符串、覆盖的输出点、源码检查结果和复查日期留档，形成可追溯的证据链。