2023年某电商平台的击原决方一次促销活动中，攻击者在一款热销商品的理解评论区里提交了一段看似普通的买家秀文字。三小时后，击原决方超过两万名浏览该页面的理解用户，其登录令牌被悄悄发送到了攻击者控制的击原决方服务器上。这不是理解电影情节，而是击原决方典型的存储型XSS攻击——恶意脚本被永久保存在了服务器数据库里，每个访问者都成了受害者。理解

XSS，击原决方全称跨站脚本攻击（Cross-Site Scripting），理解核心就一句话：攻击者让浏览器执行了本不该执行的击原决方脚本。浏览器无法区分这段脚本是理解网站自己写的，还是击原决方攻击者塞进来的。只要脚本出现在页面里，理解浏览器就照单全收。击原决方这就像你收到一封信，信封上是你朋友的字迹，但信纸里夹着一张伪造的转账指令，你以为是朋友的意思，照做了。

XSS分三种。反射型最“一次性”——恶意脚本藏在URL参数里，用户点击链接，服务器把参数直接拼接到HTML里返回，脚本执行完就没了。比如你收到一条短信：“你的订单异常，点击查看：http://example.com/search?q=<script>alert(document.cookie)</script>”。存储型最危险，脚本被存进数据库，每个访问页面的人都中招，前面那个电商案例就是。DOM型最隐蔽，服务器压根没参与，恶意数据通过前端JavaScript直接写入页面，比如从URL的hash部分取值后直接innerHTML。

我曾在一次内部安全测试中，只用了不到十秒就在某后台管理系统的用户名输入框里插入了<img src=x onerror=alert(1)>。保存后刷新页面，弹窗立刻出现。开发人员很惊讶：“我们后端明明做了转义啊。”问题出在前端——页面用JavaScript动态渲染用户名时，直接用了innerHTML而不是textContent。后端转义在传输层有效，但前端渲染时又原样还原了。这种前后端责任边界模糊导致的漏洞，比纯后端疏忽更常见。

防御XSS没有银弹，但有几条硬规则。输出编码是第一道闸门——根据数据将要放置的上下文（HTML标签内、属性内、URL、JavaScript变量）选择对应的编码方式。比如在HTML里，<必须变成<；在JavaScript字符串里，引号和反斜杠要转义。不要用黑名单过滤，攻击者总有办法绕过。用白名单，只允许明确安全的字符。

第二，Cookie加HttpOnly标志。这样JavaScript就偷不到会话令牌了。但别以为这就万事大吉——攻击者仍然可以发起请求、篡改页面内容、钓鱼。HttpOnly只是把最严重的后果砍掉了。

第三，内容安全策略（CSP）。告诉浏览器：只允许加载我指定来源的脚本。这能挡住大部分注入型XSS。但CSP配置复杂，很多网站为了省事直接开unsafe-inline，等于没开。我见过一个金融网站，CSP头写得漂漂亮亮，结果内联脚本全放行，攻击者一个<script>标签照样跑。

第四，别信任任何用户输入。包括URL参数、表单字段、HTTP头、甚至Cookie本身。有个冷门案例：某网站把User-Agent头直接显示在页面上“欢迎来自XX浏览器的用户”，攻击者伪造User-Agent为<script>...</script>，存储型XSS就成立了。

最后一点个人观察：很多团队在开发阶段用框架（React、Vue）以为自动安全了。React的JSX默认转义确实能挡住大部分，但一旦你用dangerouslySetInnerHTML或者直接操作DOM，防线就塌了。Vue的v-html同理。框架不是保险箱，它只是把危险操作变得不那么顺手。真正管用的，是每次把数据放进页面时，脑子里过一遍：这段内容来自哪里，它该被当成文本还是代码？

XSS活了二十多年，依然排在OWASP Top 10里。不是因为它难防，而是因为太多人觉得“我这儿不会出问题”。直到弹窗出现在自己网站上那天。