结论：正确实现是 synchronizer token 模式：服务端为会话生成不可预测的随机 token，下发到页面（表单隐藏域或 meta 标签），状态变更请求必须携带，服务端校验与会话绑定且一致才放行。攻击者跨站构造的请求带不出这个 token（浏览器只会自动带 Cookie，不会自动带自定义参数/头），攻击因此失效。

展开：为什么 Referer/Origin 检查不够格做主防：1）兼容性漏洞——隐私模式、企业代理、部分移动浏览器会剥掉 Referer，"无 Referer 放行"策略给攻击留了口（<meta name="referrer" content="never"> 让攻击页面不发 Referer）；2）子域被 XSS 攻破或存在开放重定向时 Referer 可以是合法的。它适合做纵深补充（Origin 头检查登录请求很有效）而非唯一防线。实现细节：token 每会话一个即可（不必每请求轮换，轮换易出并发标签页互踢问题），要足够熵（128 位随机数）、绑定会话、HttpOnly Cookie + 表单字段双提交（double submit 是无状态变体，但要配合签名否则可被 XSS 种 Cookie 绕过）；自定义头方案（X-Requested-With + 校验）对纯 JSON API 等效，因为跨站表单发不出自定义头。易错点：GET 请求有副作用时 CSRF token 救不了（<img src> 触发），先修语义；SameSite=Lax/Strict Cookie 是现代浏览器的第二道防线，但不覆盖老浏览器和子域场景。

追问方向：double submit cookie 被"Cookie 种植"攻击绕过的原理、登录 CSRF 的危害与防御。