浏览器把用户输入当成代码执行了，防御这就是核心XSS。防御的思想核心就一句话：让不可信的数据永远以数据身份出现，绝不让它有机会变成代码。防御

听起来简单，核心做起来到处都是思想坑。我见过一个电商站，防御搜索框回显关键词时用了innerHTML，核心用户搜<img src=x onerror=alert(1)>，思想页面直接弹窗。防御开发者的核心第一反应是“过滤掉<script>不就行了”，于是思想写了条正则把script标签删掉。攻击者换成<img onerror>，防御照样执行。核心这种黑名单思路从根上就错了。思想

正确的做法是上下文感知的转义。同一个用户输入，放在HTML标签之间、放在属性值里、放在<script>块内、放在URL里，需要的处理方式完全不同。比如<div>用户输入</div>，把&转成&、<转成<就够了。但如果输入落在<a href="用户输入">里，光转义尖括号没用，还得考虑javascript:伪协议。丢进<script>var x='用户输入'</script>，转义HTML实体反而无效，得用JS字符串转义。

我自己的经验是，与其在每个输出点手动转义，不如从框架层面解决。React的JSX默认转义所有插值，Vue的模板也一样。真正出事的往往是dangerouslySetInnerHTML或v-html这类逃生舱口。用它们的时候，数据必须经过严格净化，比如用DOMPurify处理后再渲染。这不是可选项，是硬性要求。

输入过滤呢？它只能算辅助手段。比如用户昵称里不该出现<，那在入库前限制字符集是合理的。但别指望靠输入过滤兜底，因为同一条数据可能在A场景是纯文本、在B场景要当HTML片段用。入库时一刀切过滤，到了需要富文本的地方反而把正常内容也杀了。输出编码才是最后一道防线，也是唯一可靠的防线。

还有个容易忽略的地方：DOM型XSS。数据不经过服务器，直接从location.hash或document.referrer取出来塞进innerHTML。服务端日志里干干净净，WAF也拦不住。前端代码里搜innerHTML、outerHTML、document.write、eval，基本能捞出八成问题。

Cookie加HttpOnly能防住XSS窃取会话，但它不阻止XSS本身。攻击者照样能改页面内容、伪造登录框、发起CSRF。别把HttpOnly当解决方案，它只是减损措施。

CSP是另一层保险。设置script-src 'self'，内联脚本和外部恶意脚本都跑不起来。但CSP配置复杂，老站点改造代价大。新项目从一开始就上CSP，比事后补救轻松得多。我习惯先用Content-Security-Policy-Report-Only跑一周，看报告里有哪些合法资源被拦，调整完再切强制模式。

说到底，XSS防御没有银弹。转义是根基，净化是补充，CSP是兜底。三层叠起来，攻击成本就上去了。最怕的是开发者觉得“我用了框架就安全了”，然后在某个深夜用v-html渲染了用户评论。漏洞往往就藏在这种图省事的瞬间。