去年有个做电商的防御方案朋友找我救火，说后台莫名多了几十个高权限账号。防御方案查日志发现，防御方案攻击者根本没碰数据库，防御方案而是防御方案伪造了一个带恶意请求的图片链接，诱导已登录的防御方案管理员点击——管理员浏览器带着合法Cookie就把添加账号的请求发出去了。这就是防御方案典型的CSRF：攻击者不窃取你的身份，而是防御方案借用你的身份。

要防住这类漏洞，防御方案核心就一句话：让服务器能分辨请求是防御方案不是用户自愿发出的。下面这几套方案，防御方案按实际项目里的防御方案可靠程度排序。

一、防御方案CSRF Token：最靠谱的防御方案防线

在表单里塞一个随机字符串，同时存一份在用户Session里。防御方案提交时服务器比对两者是否一致。攻击者从外部站点发起的请求，拿不到这个Token值，自然伪造不了。

实现上有几个坑要注意。Token必须足够随机，用secrets.token_hex(32)这类密码学安全的生成器，别用random模块。另外Token要绑定用户会话，不能全局共用。我见过有人把Token写死在JS文件里，那跟没加一样。

对于前后端分离的项目，可以把Token放在响应头里，前端每次请求时读出来塞进X-CSRF-Token头。这样比藏在表单里更灵活，也能覆盖AJAX请求。

二、SameSite Cookie：浏览器层面的天然屏障

给Cookie加上SameSite=Lax或Strict属性。Lax模式下，从外部站点发起的POST请求不会携带Cookie，而正常导航跳转的GET请求不受影响。Strict更严格，任何跨站请求都不带Cookie。

Chrome从80版本开始默认把未设置SameSite的Cookie当作Lax处理，这挡掉了不少老漏洞。但别完全依赖它——老浏览器兼容性参差不齐，而且Lax不防同站点的子域名攻击。把它当作辅助层，不是替代品。

三、验证Origin和Referer头

服务器检查请求的Origin或Referer头，确认来源域名在白名单内。这招实现简单，但Referer可能被隐私设置或代理剥离，Origin在某些旧浏览器里也不可靠。适合作为补充校验，单独用风险偏高。

四、关键操作二次验证

改密码、转账、删账号这类敏感动作，强制要求输入当前密码或短信验证码。攻击者伪造的请求里没有这些额外凭证，自然执行不了。代价是用户体验变重，所以只用在真正关键的操作上。

五、自定义请求头

要求所有状态变更请求必须带一个自定义头，比如X-Requested-With: XMLHttpRequest。浏览器的同源策略限制下，跨站的表单提交和图片请求无法设置自定义头，只有XHR/fetch能加。这招对纯表单场景无效，适合API接口防护。

实际项目里，我通常把CSRF Token和SameSite Cookie组合使用，Origin校验作为兜底。三层叠加后，基本能堵死绝大多数CSRF路径。别指望单一方案包打天下——安全从来都是纵深防御的事。