说到Web安全，跨站请求伪造（CSRF）绝对是个老牌但依然活跃的“麻烦制造者”。它利用的是用户对已登录站点的信任，诱导用户在不知情的情况下执行非本意的操作。要有效防御它，单靠一招鲜可不行，得打一套组合拳。下面这几种主流策略，各有侧重，结合起来才能构建起坚固的防线。
1. 使用随机生成的CSRF Token
这是目前最主流、最可靠的防御手段。核心思路很简单：给每个用户会话关联一个服务器生成的、不可预测的随机令牌（Token）。当用户进行敏感操作（比如修改密码、转账）提交表单时，必须将这个令牌一并提交。服务器收到请求后，会校验提交的令牌是否与当前会话中存储的令牌匹配。不匹配？请求直接驳回。
这就好比给你的每一次关键操作加上了一次性的动态口令。攻击者可以伪造请求的地址和参数，却无法猜出或窃取到这个随机的令牌，因此攻击自然失效。
2. 验证Referer头部
这个方法比较直接：服务器检查HTTP请求头中的Referer（或Origin）字段，看这个请求是从哪个页面发过来的。如果来源不是本网站合法的页面，那就很可能是跨站伪造的请求。
不过，这个方法有其局限性。Referer头在某些情况下（比如从HTTPS跳到HTTP）可能不会被发送，或者可以被用户或某些浏览器插件禁用。更关键的是，这个头部理论上是可以被篡改的。因此，它通常作为辅助验证手段，而非唯一的防线。
3. 使用SameSite Cookie属性
这是一个从浏览器层面“釜底抽薪”的策略。通过给Cookie设置SameSite属性，可以告诉浏览器在什么情况下发送这个Cookie。
- Strict：最严格，完全禁止在跨站请求中发送Cookie。
- Lax：相对宽松，允许在顶级导航（如点击链接）的GET请求中发送，但禁止在跨站的POST请求或嵌入资源（如图片、iframe）的请求中发送。
设置SameSite=Lax或Strict后，即使攻击者构造了恶意请求，浏览器也不会自动附带上用户的会话Cookie，从而从根源上切断了CSRF攻击的依赖路径。现在，这已经成为现代浏览器的推荐实践。
4. 使用双重提交Cookie策略
这个策略可以看作是CSRF Token方案的一种变体，尤其适用于前后端分离或API场景。除了在会话中存储Token，服务器还会将这个Token作为一个独立的Cookie发送给客户端。
前端Ja vaScript代码需要读取这个Cookie的值，并将其作为自定义的请求头（如X-CSRF-Token）或表单字段，随请求一起提交。服务器端同时验证请求中的Token值和Cookie中的Token值是否一致。
由于同源策略的保护，恶意网站无法读取或修改目标站点的Cookie，因此也就无法伪造这个自定义的请求头，从而实现了防护。
5. 验证请求来源
除了检查Referer，还可以通过其他方式校验请求的“出身”。例如，检查Origin头部（它比Referer更简单，且不易被篡改），或者结合校验请求的IP地址是否在可信范围内。
这对于一些API接口或特定场景的防护有一定作用，但同样不能作为唯一的依赖，因为某些请求可能没有Origin头，而IP地址也可能被伪造（尤其是在袋里环境下）。
说到底，防御CSRF没有银弹。最稳妥的做法是采用分层防御的策略：将CSRF Token作为核心防御机制，同时为所有Cookie设置SameSite属性（至少为Lax），并以验证Referer/Origin作为额外的辅助检查。对于敏感度极高的操作，甚至可以要求用户进行二次身份验证（如输入密码）。这样多管齐下，才能最大程度地将CSRF攻击的风险降到最低。
