一个攻击者能借用你的漏洞浏览器，在你登录的漏洞网站上替你发帖、转账、漏洞改密码——而你毫不知情。漏洞这不是漏洞科幻，是漏洞CSRF（跨站请求伪造）的现实。

我见过最典型的漏洞案例，是漏洞某论坛用户只是点开了一个带图片的帖子，自己的漏洞账户就被自动关注了几百个陌生账号。图片的漏洞src指向的是论坛的“关注”接口，浏览器带着他的漏洞登录Cookie去请求，服务器只认Cookie，漏洞不认发起请求的漏洞页面是谁。就这么简单，漏洞防线破了。漏洞

CSRF的核心逻辑，说白了就是“信任了不该信任的请求”。服务器看到你的Cookie，以为是你本人在操作，但它没想过，这个请求可能根本不是从你的页面发出的。攻击者只需要构造一个恶意链接或表单，诱导你点击，剩下的全交给浏览器。

你可能会问，现在不都流行前后端分离、用Token认证吗？确实，很多新项目用Authorization头传Token，CSRF基本失效——因为跨域请求不会自动带上自定义头。但老项目、内部系统、甚至一些银行网银，还在用Cookie+Session。我去年测试某个政府网站，后台管理系统的修改密码接口，连Referer都没校验，直接POST就能改。这种漏洞在真实世界里，比你想的多得多。

防御手段其实不复杂。最有效的是CSRF Token——服务器生成一个随机值塞进表单，提交时校验。但这里有个坑，Token必须绑定Session，不能是全局固定值，否则被拿到一次就全盘崩溃。第二种是校验Referer头，但浏览器有时会因隐私设置不发送Referer，导致误伤。更稳妥的是双重验证，比如敏感操作要求重新输入密码或短信验证码。别嫌麻烦，安全从来就是麻烦的。

我自己写代码时，有个习惯：凡是POST请求，一律要求自定义请求头。比如X-Requested-With: XMLHttpRequest，因为跨域表单提交没法带这个头。这招能挡住90%的简单CSRF，但不适用于所有场景——如果你确实需要接收跨域请求，还是老老实实上Token吧。

还有个容易被忽略的点：CSRF不只能通过GET触发。很多开发以为把接口改成POST就安全了，攻击者照样能用隐藏表单自动提交。真正要防的是“无痕请求”——攻击者不需要看到响应内容，只要请求被执行就够了。所以别指望靠请求方式保平安。

说到底，CSRF是个“老古董”漏洞，2001年就被提出，到现在还在肆虐。原因不是技术难，而是开发者懒。我见过太多项目，上线前只测功能，不测安全。等到被薅羊毛或被删库了，才想起来补漏洞。你与其依赖框架自带的防护，不如自己理解原理，亲手写一遍校验逻辑。踩过坑，才记得牢。

最后说句实在话——如果你在维护一个老系统，别急着重构，先花半天时间把所有写操作接口过一遍，检查有没有Token校验。没有的话，加上。半天功夫，能省下未来无数个不眠夜。