企业级应用如何设计一套可靠的 CSRF 防护架构？

企业级 CSRF 防护不要只靠某个接口临时加 Token，应该做成统一安全能力：入口层先挡明显跨站请求，应用层校验会话和 Token，高风险业务再做二次确认。架构上要兼顾多域名、SSO、微服务、灰度发布和审计，否则规则一上线就可能误伤登录、支付或第三方集成。

追问

校验放网关还是业务服务？

最好两层都做。网关做通用拦截，如 Fetch Metadata 和 Origin 白名单；业务服务做 Token 是否绑定当前用户、租户和操作。

Token 应该怎么存？

服务端状态 Token 可放 Redis，便于吊销和一次性使用；双提交 Cookie 性能好，但密钥轮换和重放控制要设计清楚。

SSO 和多域名会影响 SameSite 吗？

会遇到边界。跨站登录跳转可能需要 SameSite=None; Secure，但业务写操作仍要校验 Origin 和 Token。

落地最大坑是什么？

没有资产清单就全站强制。老系统可能有跨域表单、WebView、第三方回调，应先观测日志再分级灰度。

写段配置

nginx
if ($http_sec_fetch_site = "cross-site") { set $csrf_block 1; }
if ($request_method !~ ^(GET|HEAD|OPTIONS)$) { set $csrf_block "${csrf_block}1"; }
if ($csrf_block = "11") { return 403; }