nginx不能替代后端csrf token验证，但可在网关层通过referer/origin校验、token透传与日志增强形成纵深防御，须配合samesite、自定义请求头及后端强token机制。
Nginx 本身不能完全解决 CSRF，但可以在网关层做第一道拦截，把明显非法的跨站请求挡在外面，减轻后端压力。关键不是替代后端 Token 验证，而是和它配合形成纵深防御。
Referer 校验：适合表单类请求
浏览器在普通表单提交时会自动带上 Referer 头，Nginx 可据此判断来源是否可信。
- 必须包含 none 和 blocked：用户直接输入 URL、从书签打开、或经某些代理转发时，Referer 可能为空或被过滤，不加这两项会导致大量误拦
- 用 server_names + 显式通配 比硬写正则更稳：比如 server_name 是 admin.example.com，就配
valid_referers none blocked server_names *.example.com; - 避免字符串模糊匹配：像
"example.com"会误放过evil-example.com，真要用正则就得锚定开头和结尾，例如~*^https?://([a-z0-9.-]+\.)?example\.com(/|$) - 校验动作统一放在 location 块开头：
if ($invalid_referer) { return 403; }，别混在 proxy_pass 后面
Origin 校验：更适合前后端分离的 API
Origin 头由浏览器在 CORS 请求（如 fetch、XMLHttpRequest）中强制添加，且不可被前端 JS 修改，比 Referer 更可靠，但它不会出现在普通表单提交中。
- 优先用 map 指令做白名单映射：比反复 if 判断更高效、更安全（Nginx 官方明确不建议在 location 中滥用 if）
- Origin 只有在跨域请求时才存在，所以对同源页面内发起的 AJAX 也有效，但对传统 form submit 无效
- 需注意旧版 IE 不支持 Origin，若兼容性要求高，不能单独依赖它
配合后端 Token 的基础协同方式
Nginx 层无法验证动态 Token，但可以辅助做初步筛选或透传控制。
- 可配置 透传特定请求头，比如把 X-CSRF-Token 从客户端原样转发给后端，避免被 Nginx 无意丢弃
- 可用 rewrite 或 map 提取 cookie 中的 token 片段，记录到日志或 header 中，供后端快速关联分析
- 禁止在 Nginx 层做“token 相等性判断”：它没有运行时状态，无法生成或校验加密 Token，强行实现反而引入逻辑漏洞
不能跳过的配套措施
只靠 Nginx 校验 Referer 或 Origin 远不够，必须同步落地其他防护点。
- 后端必须启用强 Token 机制（如同步令牌模式），且每次敏感操作都校验
- Cookie 设置 SameSite=Lax 或 Strict，从源头限制浏览器自动携带 Cookie 的场景
- 敏感接口强制要求 自定义请求头（如 X-Requested-With），Nginx 可检查该头是否存在，因为跨域 POST 表单无法携带它
- 所有校验失败请求，统一返回 403 并记录日志，便于后续分析攻击特征
