一个搜索框，漏洞输入<script>alert('xss')</script>，漏洞点搜索。漏洞页面弹了个窗。漏洞就这么简单，漏洞一个漏洞诞生了。漏洞

这是漏洞我在测试某后台管理系统时遇到的。那个搜索框把用户输入原封不动地塞进了HTML里，漏洞连个转义都懒得做。漏洞开发者大概觉得，漏洞一个内部系统，漏洞谁会去攻击它？漏洞可问题是，攻击者根本不需要“谁”，漏洞只需要一个能诱导管理员点击的漏洞链接。

XSS的漏洞全称是跨站脚本攻击。名字听着唬人，原理却朴素得让人叹气——你的网站把用户输入当成了代码执行。攻击者不直接打你，他往你的页面里塞一段脚本，等你的用户访问时，脚本就在他们的浏览器里跑起来。偷cookie、改页面、伪造表单，什么都干得出来。

有一次我在一个电商平台的产品评论里看到这么一段：<img src=x onerror=alert(document.cookie)>。评论审核通过了，图片加载失败，错误处理函数触发了。如果那段代码不是弹窗，而是把cookie发到某个服务器，用户账号就悬了。更讽刺的是，那个平台的安全团队刚发过公告，说他们“高度重视用户数据安全”。

存储型XSS比反射型更阴险。反射型是你得骗用户点链接，存储型直接藏在数据库里，每个访问页面的人都中招。论坛签名、个人简介、留言板，都是重灾区。我见过一个论坛，用户签名档里塞了恶意脚本，结果版主每次审核新帖都中招——因为后台页面把签名档也渲染出来了。

修复XSS难吗？不，难的是让人意识到它值得修。很多开发者的第一反应是“我用的是框架，框架自带防护”。但框架只保护它自己生成的输出，你要是用了v-html、dangerouslySetInnerHTML，或者服务端拼了字符串，框架也拦不住。还有个常见误区是只过滤<script>标签，但XSS的载体远不止script——<img onerror>、<svg onload>、javascript:伪协议，变种多到数不过来。

真正的根治办法只有一个：对所有输出做上下文感知的编码。HTML标签里就转义标签字符，属性里就转义引号，script里就做JS转义。别相信任何输入，也别相信框架的默认配置。安全不是加个WAF就完事，那是给漏洞外面加了个罩子，罩子总有被捅破的时候。

我见过最离谱的一次，是某政府网站把用户填的姓名直接拼进页面标题。攻击者把名字改成</title><script>...</script>，标题被闭合了，脚本执行了。这活儿根本不需要什么高深技术，就是认真看了下页面源码。

XSS漏洞之所以泛滥，是因为它太“礼貌”了——不炸服务器、不改数据、不显山露水，顶多弹个窗。但正是这种隐蔽性，让它成了窃取信息的温床。你永远不知道哪个不起眼的输入框，正等着把你的用户卖出去。

修复它，别偷懒。转义函数写起来不费事，但漏掉一个输出点，前面全白干。安全这件事，从来都是木桶效应——最短的那块板决定你能装多少水。