CSRF漏洞的漏洞防御，本质上是御方一场信任边界的博弈。攻击者伪造请求，漏洞让服务器误以为那是御方用户本人的操作——换密码、转账、漏洞改邮箱，御方全在用户不知情下发生。漏洞最典型的御方场景：你登录了银行网站，又去逛了恶意论坛，漏洞论坛里藏着一张图片，御方加载它时浏览器自动携带你的漏洞银行Cookie，向转账接口发起了请求。御方服务器一看，漏洞Cookie有效，御方请求合法，漏洞钱就转走了。

防御的核心思路就一条：让服务器能分辨“用户主动发出的请求”和“被第三方伪造的请求”。光靠Cookie不够，因为Cookie是自动携带的。所以得加一道只有浏览器页面才能生成的“暗号”。

最常用的暗号是CSRF Token。服务器在渲染表单时生成一个随机字符串，塞进页面隐藏字段里。用户提交时，Token跟着表单一起回来。攻击者的恶意页面拿不到这个Token——跨域读取被同源策略挡住，所以他构造的请求里必然缺这一项。服务器只要校验Token一致，就能放行。这方案简单有效，但有个坑：如果Token放在Cookie里，攻击者照样能带上。必须放在请求体或自定义请求头里，才能保证“只有页面能拿到”。

第二个防御手段是校验请求来源。HTTP头里的Origin和Referer能告诉服务器请求从哪来。如果Origin不是自家域名，直接拒绝。这招防得住大部分跨站请求，但Referer在隐私模式下可能被浏览器省略，Origin在部分旧浏览器里也可能缺失——所以不能只依赖它，得和Token配合用。

还有个偏门但实用的技巧：在关键操作前要求用户重新输入密码或验证码。比如转账时输支付密码，改绑定手机时收短信验证码。这等于把信任基础从“浏览器自动携带的凭证”升级到“用户主动输入的信息”，攻击者没法伪造，因为他不掌握这些动态值。缺点很明显——用户体验变差，所以只用在高风险操作上。

另外，别忽视双重Cookie验证的变种。服务器在Cookie里放一个随机值，同时要求请求参数里带同一个值。攻击者读不到Cookie内容，也就没法在参数里填对。但注意，如果站点存在XSS漏洞，这招就废了——XSS能读取页面里的任何东西，Token也好、Cookie也罢，全暴露。所以CSRF防御的前提是XSS必须先堵死。

我自己调试过不少被CSRF攻击的站点，发现一个共性：凡是只依赖Post请求做状态变更的，都容易中招。攻击者用表单自动提交就能伪造Post。真正稳妥的做法是，把Token放在自定义请求头里，比如X-CSRF-Token，用JavaScript的fetch或XMLHttpRequest发送。这样攻击者连“构造表单”这条路都走不通，因为浏览器跨域时没法自定义头部——除非对方站点本身允许CORS。

最后提个现实问题：很多框架自带CSRF防护，比如Spring Security、Django的CsrfViewMiddleware。但开发图省事，经常关掉或者只开了部分接口。我的建议是，默认全开，白名单放行确需开放的回调接口。别嫌麻烦，被刷一次转账的损失，比写代码的麻烦大得多。