CSRF（跨站请求伪造）的属于防护，本质上就一句话：让服务器能分辨出“这个请求到底是漏洞不是用户本人主动发起的”。围绕这个核心，防护方法业界沉淀出几种行之有效的有那手段，但它们的属于适用场景和坑，你得心里有数。漏洞

最常用的防护方法办法是同步令牌（Synchronizer Token）。服务器在渲染页面时，有那往表单里塞一个随机的属于、一次性的漏洞token，存在session里。防护方法用户提交时，有那服务器比对表单token和session里的属于值是否一致。这个方案几乎能防住所有CSRF，漏洞因为攻击者无法读取目标站点的防护方法响应，自然拿不到那个token。但问题也明显——如果你的站点用了大量AJAX，每个请求都得手动带上token，写起来烦，还容易漏。我见过不少团队把token放在全局变量里，结果前端渲染时被第三方脚本顺手偷走，那就白搭了。

另一个主流思路是检查请求头中的Origin或Referer。原理很直白：CSRF是跨域的，攻击页面发起的请求，其Origin头一定不是你的站点。服务器只要校验这个头，不是自家域名就直接拒绝。这招实现成本极低，几乎零侵入，适合做全局过滤器。但Referer有个毛病——用户浏览器可能因为隐私设置不发送它，或者在某些跳转场景下被剥离。所以更稳妥的是优先看Origin，它更可靠。不过，别指望这招能挡所有情况，比如同站子域间的漏洞，它就无能为力了。

再进阶一点，是自定义请求头配合CORS策略。很多API接口只接受JSON数据，并要求请求头里带一个自定义字段，比如X-Requested-With: XMLHttpRequest。浏览器在跨域请求时，如果不是简单请求，会先发一个OPTIONS预检。如果服务器没在CORS响应里明确允许这个自定义头，浏览器就直接拦截，请求根本发不出去。这等于把CSRF的防线前置到了浏览器层，省心。但注意，这依赖CORS配置的正确性——你要是图省事设了Access-Control-Allow-Origin: *，那就等于把门拆了。

还有一种偏冷门但很硬核的方法：双重提交Cookie。服务器不存token，而是让客户端在请求参数里带上一个值，同时这个值也以Cookie形式存在。服务器比对两者是否一致。因为攻击者无法设置目标域的Cookie（除非有XSS辅助），所以伪造不出来。好处是无需服务端存储，适合分布式无状态架构。坏处是如果站点本身存在任何子域漏洞或Cookie被httpOnly之外的脚本读到，这层防护就形同虚设。

最后，说点实际的。我自己处理过几个CSRF漏洞，发现多数不是方案选错，而是执行不到位。比如token用了但没绑定session，导致只要拿到一次token就能反复用；再比如对GET请求也做了状态修改，而CSRF防护往往只盯着POST。所以我的建议是：能上同步令牌就别偷懒用Referer，同时把所有写操作强制改成POST，再配合SameSite Cookie属性——现在主流浏览器默认Lax，已经能挡掉绝大多数跨站POST了。这套组合拳下来，剩下的漏洞基本都是你业务逻辑自找的了。