前端安全实战：XSS 与 CSRF 的防御要落在每一层，而不是只靠框架默认

前端框架自带的转义让很多人以为 XSS 已经解决，浏览器 SameSite Cookie 又让很多人以为 CSRF 已经消失。现实是：只要有一个富文本渲染、一个 innerHTML、一次跨站请求处理不当，攻击面立刻就打开。防御必须分层，每一层堵住一类问题。

XSS：输出编码是底线，富文本是重灾区

存储型 XSS 最常见于评论、昵称、富文本编辑器：攻击者提交一段脚本，之后每个打开页面的用户都会中招。框架的模板转义能挡住普通插值，但挡不住主动使用 v-html、dangerouslySetInnerHTML 或 innerHTML 的地方。规则很简单：能不用富文本就不用；必须用时，先用成熟的净化库白名单过滤标签和属性，禁止 script、iframe、on* 事件属性和 javascript: 协议链接；同时设置内容安全策略 CSP，限制脚本来源，即使有漏网的脚本也难以执行。反射型 XSS 则来自 URL 参数直接回显到页面：任何从地址栏、搜索框取来的内容，展示前都要编码，跳转链接要校验协议，防止 javascript: 伪协议被利用。DOM 型 XSS 更隐蔽：前端代码从 location.hash 或 postMessage 里取值后拼进 DOM，审计时要重点看这些数据源的流向。

CSRF：Cookie 自动携带是根源

浏览器会在跨站请求中自动带上 Cookie，这就是 CSRF 的根基。防御组合拳包括：关键操作使用 POST 并校验 CSRF Token，Token 与会话绑定且每次会话更换；Cookie 设置 SameSite=Lax 或 Strict，敏感操作再加二次确认；服务端校验 Origin 与 Referer 头，拒绝来源不明的跨站请求；涉及资金、密码修改、绑定变更的操作，要求重新输入密码或二次验证，即使 Token 泄露也能多一道屏障。要注意 SameSite 不是万能药：同站子域攻击、GET 请求改状态的老接口，仍然可能绕过，必须配合 Token 校验。

容易被忽视的三个点

第一是第三方脚本：统计、客服、广告脚本一旦被投毒，等于把执行权交给了别人，引入前要评估供应商，重要页面尽量用 SRI 校验脚本完整性。第二是敏感信息不要放前端：localStorage 里的 Token 会被 XSS 直接偷走，优先用 HttpOnly Cookie 存会话凭证，前端只保存非敏感的状态。第三是错误信息与接口返回：调试信息、堆栈、内部路径不要原样返回给前端，攻击者常从这些细节里拼出攻击路径。安全上线前做一次清单检查：所有用户输入是否编码、富文本是否净化、CSP 是否生效、关键接口是否有 Token、Cookie 属性是否正确、第三方脚本是否有完整性校验。把这六项做成发布检查项，比事后修补漏洞便宜得多。

上线后的持续运营同样重要

防御上线不是终点。CSP 上报接口要持续收违规报告，从中发现漏网的内联脚本或新增的第三方来源；依赖库要定期扫描已知漏洞，及时升级存在 XSS 相关修复的版本；接口层面要记录异常请求模式，例如短时间内大量携带脚本片段的参数，可能是有人在探测注入点。团队内部也要形成共识：新功能评审时，把“用户输入从哪里来、经过哪些拼接、最终渲染到哪里”作为必问问题，画出数据流再上线。很多 XSS 漏洞不是技术上防不住，而是评审时没人追问数据的完整流向。把安全检查前移到设计评审，成本最低，效果也最稳定。