很多人把XSS当成洪水猛兽，不属仿佛一个弹窗就能让网站裸奔。跨站这种焦虑多半是脚本被安全厂商的营销话术放大的。实际上，漏洞XSS的危害危害分级非常明确——绝大多数场景下，它造成的不属破坏远不如一个被爆破的弱口令FTP账号来得直接。

我见过最典型的跨站“无害XSS”，是脚本某个老牌论坛的搜索框。开发者忘了对关键词做HTML实体编码，漏洞导致搜索“”时页面会弹窗。危害但仅此而已。不属攻击者无法窃取Cookie，跨站因为该论坛的脚本会话标记绑定在IP段上，且HttpOnly标志早就加了。漏洞更关键的危害是，这个搜索页没有任何用户生成内容，也没有后台管理入口。攻击者能做的，就是在自己的浏览器里吓自己一跳。

另一个被误判的例子是某些静态页面上的反射型XSS。比如一个企业官网的404页面，把错误路径直接反射回页面。攻击者构造一个恶意链接发给受害者，受害者点击后页面确实会执行脚本——但脚本能做什么？它无法读取当前页面的DOM之外的数据，也无法跨域请求。网站没有登录态，没有用户数据，没有支付流程。脚本最终的效果，等同于在受害者屏幕上画个鬼脸。这种攻击的“危害”，甚至不如一封垃圾邮件里的钓鱼链接。

真正的XSS危害，需要同时满足三个条件：存在可存储用户输入的持久化场景、目标页面承载高价值会话数据、且浏览器端缺少基础防护（如CSP、HttpOnly）。缺了任何一个，危害都会断崖式下降。我审计过一个内部OA系统，它的公告栏存在存储型XSS，但系统强制使用双因素认证，且所有接口都校验了自定义请求头。攻击者注入的脚本即便执行，也拿不到任何有效会话——因为会话根本不在Cookie里，而在内存token中。最终这个漏洞被定级为“低危”，修复优先级排在了数据库慢查询后面。

当然，说“不属于危害”不等于可以放任不管。XSS是前端漏洞的“入门券”，它往往能和其他漏洞串联成更复杂的攻击链。但孤立地讨论一个反射型、无持久化、无敏感数据交互的XSS，它的实际危害可能比一个未修复的CVE-2019-0708低几个量级。安全圈喜欢把漏洞的“理论影响”和“实际危害”混为一谈，这导致很多开发团队为了一个弹窗漏洞加班到深夜，却对旁边那个可匿名访问的备份文件目录视而不见。

我始终认为，安全评估应该回归到业务逻辑本身。一个没有任何用户数据、不依赖会话状态、也不与外部服务交互的静态页面，就算被XSS打穿，攻击者能拿到什么？一张空白页面的控制权？那不如直接去攻击托管这台服务器的云厂商。风险要放在真实威胁模型里看，而不是对着CVSS评分表做数学题。