这种漏洞，静态扫描工具根本查不出来。它只盯着危险函数，比如`innerHTML`、`document.write`，但真正的风险往往藏在业务逻辑的缝隙里。所以我做审计时，习惯先问一个问题：这个数据从哪来，要到哪去？如果中间隔了三层函数调用，每层都做了点字符串处理，那基本可以断定，净化逻辑大概率已经被拆得七零八落了。

还有个更隐蔽的坑，是富文本编辑器。现在哪个后台不用个UEditor、Quill之类的？编辑器自带XSS过滤，但很多人不知道，这些过滤是基于白名单标签的，而白名单本身就有漏洞。比如允许``标签，但没限制`src`属性——那就可以写``。更恶心的是，有些编辑器允许自定义CSS，而CSS里可以用`expression()`（老IE）或者`url(javascript:...)`。审计这类系统，你得连编辑器的源码一起看，光看业务代码等于白干。

说回工具。市面上商业的、开源的扫描器我基本都摸过，Fortify、Checkmarx、SonarQube，各有各的脾气。它们最大的通病是误报率高得离谱，经常把没问题的代码标红，又把真正的洞漏过去。有个项目，SonarQube报了40个XSS，我一个个人工复核，最后确认能利用的只有3个。而那3个，恰好是扫描器标记为“低风险”的。所以我现在的工作流是：用工具做粗筛，然后手动追数据流，重点看那些“看起来安全”的代码——因为攻击者比你想象的有耐心，他会试遍每个输入点，直到找到那个你忘了过滤的地方。

最后说个反直觉的事。有时候，修XSS修得太狠反而会引入新洞。比如有人为了防XSS，把所有输出都做了HTML实体编码，结果某个功能需要输出一段JSON给前端JS解析，编码后的引号直接让JSON解析崩溃，功能挂了。更糟的是，如果编码逻辑写在数据库层，那所有取出来的数据都被转义了一遍，再经过一次转义，就变成双重编码，前端显示全是乱码。所以审计时我特别反感那种“一刀切”的修复方案——安全不该是给所有数据戴上镣铐，而是该在正确的位置做正确的转义。输出编码、输入校验、Content-Security-Policy，三层都做到位，比什么“万能过滤函数”靠谱得多。

XSS审计这事儿，说白了就是跟开发者玩心理战。他留下一个疏忽，你就要顺着那条数据流，走到他没想到的角落。工具只是拐杖，真正的判断力，还是得靠一遍遍读代码、想业务场景堆出来。就像那个凌晨两点让我发呆的payload，最后查出来是开发在拼接SQL时顺手把参数带进了HTML模板，他自己都没意识到。这种洞，扫描器永远发现不了，只有人，才会问“为什么这里会多一个单引号”。