一个经典的跨站场景：攻击者在评论区提交了``，管理员后台打开页面，脚本弹窗出现——cookie被偷了。漏洞这是分类跨站脚本（XSS）最直白的形态，但现实远不止这么简单。跨站根据攻击载荷的脚本存储与触发方式，XSS大致能分成三类，漏洞每一类的分类攻击路径和防御思路都截然不同。

第一类是跨站反射型XSS。攻击者把恶意脚本塞进URL参数里，脚本诱导受害者点击。漏洞服务端没有对参数做充分过滤，分类直接把它拼进了响应页面。跨站用户点开链接，脚本脚本在浏览器里执行，漏洞整个过程像是一次“反射”——你发出去什么，页面就弹回什么。这种攻击的典型场景是搜索框：你搜``，结果页把这段文字原样显示出来，图片加载失败触发onerror，脚本跑了。反射型XSS的最大特点是一次性，脚本不在服务器上驻留，只对点击了恶意链接的人生效。所以攻击者得费心思把链接包装得足够诱人，或者配合短链接、二维码来传播。

第二类是存储型XSS，也是最危险的一类。脚本被永久保存在服务器端——比如论坛帖子、用户昵称、商品评论里。任何访问该页面的用户都会中招，包括管理员。2018年某电商平台就出过事：攻击者把恶意脚本写进商品标题，后台审核人员一打开商品列表，脚本就窃取了管理员的会话凭证，整个后台被接管。存储型XSS的破坏力在于持久性，它像一颗埋在地雷，谁踩谁炸。更麻烦的是，这类漏洞经常藏在富文本编辑器、Markdown渲染器等“允许用户输入HTML”的功能里，过滤规则稍有不慎就会被绕过。

第三类是基于DOM的XSS，跟前两类有本质区别。前两种问题出在服务端——服务器没过滤好输入就输出了。而DOM型XSS纯粹是前端JavaScript的锅：页面代码从URL、localStorage或postMessage里取数据，然后直接用innerHTML或document.write写进页面。攻击者构造特殊URL，让前端代码自己把恶意脚本“翻译”成可执行内容。有个真实案例：某在线文档工具用`location.hash`传递分享密码，前端拿到hash值后直接拼进DOM，攻击者只需把`#`后面的内容改成`

三种类型不是完全割裂的。反射型XSS如果配合攻击者的服务器，也能变成“一次性存储”——比如把payload存在自己的服务器上，再用短链接跳转。而DOM型XSS有时候和反射型混在一起，因为URL参数既会被服务端读取，也会被前端读取。但区分它们仍然有意义：修复反射型XSS主要靠服务端输出编码，修复存储型需要加强输入过滤和上下文感知的转义，修复DOM型则得审查前端所有操作DOM的代码路径，用textContent代替innerHTML，避免把不可信数据传给eval、setTimeout这类危险函数。

我见过不少开发者以为“只要过滤了script标签就安全了”，结果被``或`数据与代码的边界被打破。把用户输入当成纯文本处理，永远比试图“清洗”HTML更稳妥。下次你写一个展示用户评论的页面时，不妨想想：如果这里塞进一段能读取localStorage的脚本，会发生什么？