2005年冬天，跨站MySpace上一个叫Samy的脚本小伙子写了段JavaScript。这段代码会在用户浏览他的攻击个人主页时自动执行，把用户自己加为好友，跨站并在简介里植入"but most of all,脚本 samy is my hero"。结果呢？攻击不到24小时，超过100万用户中招。跨站MySpace紧急关站清理。脚本这就是攻击XSS——跨站脚本攻击最经典的案例之一。

说白了，跨站XSS就是脚本攻击者把恶意脚本塞进了网页里，其他用户访问这个页面时，攻击浏览器以为这段脚本是跨站网站自己写的，于是脚本老老实实执行。浏览器分不清哪些代码是攻击站长写的、哪些是攻击者注入的，只要出现在HTML里，它就照单全收。

常见的注入方式有三种。第一种叫存储型，恶意代码被存进了服务器数据库，比如论坛帖子、用户评论。你发一条评论，里面夹了<script>标签，服务器没做过滤直接存了，后面每个看到这条评论的人都会中招。这种最危险，因为不需要诱导点击，访问即触发。第二种叫反射型，恶意代码藏在URL参数里，服务器把参数值原样吐回页面。攻击者得精心构造一个链接，骗你点。比如http://example.com/search?q=<script>...，你点进去，服务器把你的搜索词直接显示在页面上，脚本就跑了。第三种是DOM型，整个攻击过程发生在浏览器端，服务器根本不知情。前端JavaScript代码从URL里取数据、用innerHTML往页面里插，就把恶意内容带进去了。

很多人觉得XSS就是弹个alert框，没什么大不了。这种想法太天真了。弹框只是安全研究者证明漏洞存在的方式。真正的攻击可以偷Cookie、劫持会话、伪造登录、篡改页面内容、记录键盘输入、甚至控制浏览器发起内网扫描。你想想，如果一个电商网站的评论区被注入了脚本，攻击者就能拿到所有浏览者的登录凭证，这跟直接交出账号密码有什么区别？

防御这件事，说复杂也复杂，说简单也简单。核心原则就一条：永远不要信任用户输入。输出到HTML时做实体编码，<变成<，>变成>，脚本标签就废了。不同上下文编码规则不一样，HTML属性里、JavaScript变量里、CSS里，各有各的转义要求，不能一套规则走天下。

Cookie加HttpOnly标记也很关键。加了之后，JavaScript读不到这个Cookie，就算XSS成功了，攻击者也偷不走会话凭证。这算是最后一道防线，但不能只靠它，因为攻击者还能干别的事。

还有个东西叫CSP，内容安全策略。通过HTTP响应头告诉浏览器，只允许加载哪些来源的脚本。写得好，内联脚本直接禁掉，XSS的杀伤力大幅下降。不过这玩意儿配置起来挺折腾的，很多站点开了CSP之后自己功能先挂了，得慢慢调。

我见过不少开发者觉得用了React、Vue这些框架就万事大吉了。框架确实默认做了转义，但架不住你自己用dangerouslySetInnerHTML或者v-html。这些API存在是有原因的，但每次用都是在刀尖上跳舞。框架给你安全默认值，你偏要手动绕过，那出了事真怪不了别人。

XSS活了二十多年，至今还在OWASP Top 10里待着。不是因为它多难防，而是因为开发者总在奇怪的地方偷懒。用户输入过滤了吗？输出编码了吗？CSP配了吗？Cookie标记加了吗？四个问题问下来，能全答"是"的站点，比想象中少得多。