前端安全布防：从一次XSS攻击看输入过滤方案

那是一个再平常不过的周二下午，测试同事突然在群里丢了个链接，附言“评论区好像有点不对劲”。点开一看，一段 <img src=x onerror=alert(document.cookie)> 正安安静静地躺在某篇文章的留言区里。虽然只是个无害的弹窗，但在场的人都清楚——如果这段脚本被换成窃取凭据或篡改页面的恶意代码，后果不堪设想。

事故现场：漏洞是怎么被放行的

排查时发现，问题出在我们对用户输入“过度信任”上。表单提交后，文本内容经过一个简单的正则替换（只过滤了 <script> 标签）就被存储进数据库，前端又在渲染时直接把它 innerHTML 到了页面上。

这大概是很多团队都经历过的“经典翻车”：过滤规则只会匹配已知的恶意模式，比如 <script> 或 javascript:，但攻击者根本不需要走这些“老路”。<img> 标签的 onerror 事件、<svg> 的 onload 属性、甚至通过 CSS 的 expression（旧版 IE）都能让脚本改头换面。正则过滤在当时也许能拦住“小学生攻击者”，但面对一个随手翻翻 OWASP 文档的人，它就像纸糊的盾牌。

第一道防线：充分解码后的输入校验

那次事故之后，我们重新整理了思路。所谓“输入过滤”，本质上不是在过滤“标签”，而是在过滤“状态”。有效的方式是：在白名单策略下，只允许你确信的数据结构通过。

具体而言，对于用户提交的内容：

• 严格校验语义，而不是屏蔽字符串。比如邮箱就老老实实地用 type=email 约束格式，数字就用 Number.isInteger 去验证，富文本则需要走经典的“允许标签 + 允许属性”白名单模式。只有不在名单里的标签（如 script、iframe、object）才会被剔除。
• 优先级是“编码”而非“删除”。你不能确定未来会漏掉什么 onerror 变种，但确定的是：把它当作纯文本展示，就永远不会被解析成可执行代码。与其在服务端费力剔除危险标签，不如在存储前做一层 htmlspecialchars 转义，让 < 变成 <。前端拿到这段安全的文本，用 textContent 而不是 innerHTML 渲染，就彻底断了注入的路。

纵深防御：把宝押在最后一公里

但如果你以为把“输入校验”做好就万事大吉，那还远远不够。Web 前端的攻击链往往不只存在于一个入口，XSS 的形态还有 DOM-based 和存储在第三方库里的各种变种。前端布防真正的核心，是永远假设输入是恶意的，但不再依赖输入来阻挡所有攻击。

为此我们做了两手准备：

• 输出编码放在首位。对于任何要插入 HTML 上下文的数据，在客户端渲染时统一走 escapeHtml 工具函数，在 URL 跳转前统一做 encodeURI 并校验协议只允许 http/https。工程规范上，明确禁止在业务代码中直接拼字符串往 innerHTML 里塞东西，代码审查时就拦下。
• 加上 CSP（内容安全策略）作为兜底。即使千防万防还有漏网之鱼，只要页面设置了 script-src 'self'，浏览器就会直接拦掉所有内联脚本和外部注入，让恶意代码“哑火”。

从拦截到习惯

回看这次攻击，真正有价值的不是那几条修复代码，而是团队对“数据与代码分离”的敬畏。前端安全布防不是能一次性解决所有问题的银弹，而是一组相互补充的约定和机制。在代码里，我至今保留着那次修复时写的注释：

// 这里不用 innerHTML，也别想着只过滤 script。
// 把所有输入都当作来自最危险的黑客——转义它，然后 trust nothing。

从那以后，每当我们讨论某个功能要实现“点击评论展示高亮”时，第一个问题永远是：这些内容到底是什么，应该以什么身份出现在页面上？答案清晰了，防御自然也就有了方向。