如何防御 CSRF 攻击才不会只防住一半？

防御 CSRF 的核心，是阻止攻击者借浏览器自动携带 Cookie 的能力替用户发起敏感请求。只要登录态放在 Cookie 里，转账、改邮箱、删数据、改密码这类接口都要按跨站诱导来防。稳妥方案是 CSRF Token 打底，再配合 SameSite、Origin 校验和高风险操作二次确认。

追问

为什么自定义请求头能缓解 CSRF？

普通跨站表单、图片、脚本请求不能随意带 X-CSRF-TOKEN。攻击者若用 fetch 加自定义头，会触发 CORS 预检。

SameSite=Lax 够不够？

对普通站点很有帮助，但不能当唯一防线。浏览器兼容、跨站跳转、第三方嵌入和历史客户端都会带来边界。

双重提交 Cookie 有什么限制？

它把 Token 同时放在 Cookie 和请求参数里。若子域可写 Cookie 或站点有 XSS，攻击者可能伪造或读取 Token。

发现漏洞后优先修哪里？

先修所有依赖 Cookie 登录态的写接口，尤其是资金、权限、账号资料和删除类操作。随后补自动化测试。

示例

html
<input type="hidden" name="csrf_token" value="{{token}}">