nginx 中 cors 与 csrf 必须职责分离：cors 仅声明跨域响应头，不参与安全校验；csrf 防护应独立作用于敏感写路径，依赖 token 验证而非 origin 头，避免白名单耦合与凭证跨域提交。
在 Nginx 中同时处理 CORS 和 CSRF 防护时，关键不是“让两者协同”，而是明确分工：CORS 解决的是浏览器同源策略下的资源访问许可问题；CSRF 防护解决的是请求身份合法性验证问题。二者作用层不同、目标不同，强行混用配置反而会引发冲突——比如用 Origin 头做 CSRF 判断，却在 CORS 配置中动态放行该头，就可能绕过防护。
区分 CORS 与 CSRF 的职责边界
CORS 响应头（如 Access-Control-Allow-Origin）只是告诉浏览器“这个源可以读取响应”，它不校验请求是否可信，也不阻止恶意请求发出；CSRF 防护则必须验证“这个请求是不是用户本意发起的”。Nginx 层能做的 CSRF 拦截，应独立于 CORS 头的注入逻辑，避免把安全决策绑定在跨域声明上。
- CORS 配置只负责响应头声明，且仅对合法跨域场景生效（例如前端调用 API）
- CSRF 防护应作用于所有敏感写操作路径（如
POST /api/transfer），无论是否跨域 - 不要用
$http_origin的值直接作为 CSRF 放行依据——Origin 可被构造，仅适合做初步白名单过滤，不能替代 token 验证
避免 Origin 检查与 CORS 白名单耦合
常见错误是把同一套域名白名单既用于 Access-Control-Allow-Origin，又用于 if ($http_origin !~ ...) 拦截 CSRF。这会导致：一旦某个前端域名被加入 CORS 白名单，它就自动获得绕过 CSRF 检查的权限。
- 正确做法：CORS 白名单用
map指令定义（如只允app.company.com、admin.company.com），而 CSRF 检查使用更严格的规则，例如限定只允许同主域或特定内部来源 - 对非浏览器客户端（如 curl、Postman）或服务间调用，Origin 头可能缺失或不可信，此时应跳过 Origin 检查，转而依赖 token 或 IP 白名单
- 若必须检查 Origin，建议配合 Referer + 自定义 header（如
X-Request-ID）做多因子初筛，而非单一依赖
敏感接口禁用 credentials 与放宽 CORS 并存
当接口需防 CSRF 时，最简单有效的办法是：不接受带凭证的跨域写请求。这意味着对 POST/PUT/DELETE 等敏感方法，主动拒绝 Access-Control-Allow-Credentials: true，并确保 Access-Control-Allow-Origin 不匹配任意含用户上下文的前端源。
- 对登录、支付等关键接口，可配置专用 location，只允许同源调用：
add_header 'Access-Control-Allow-Origin' ''（空值）或干脆不加该头，使浏览器强制拦截跨域请求 - 若业务必须支持跨域提交，改用“双重提交 Cookie”方案：前端将 CSRF token 同时写入 Cookie 和请求 body/header，Nginx 用
map提取两者并比对（需启用ngx_http_map_module和正则提取能力） - 静态资源（JS/CSS/字体）和只读 API 可宽松配置 CORS，但敏感操作路径必须单独限制，避免“一配全放”
推荐组合策略：分路径、分方法、分头控制
一个稳健的配置结构是按请求特征分层控制：
-
读接口（GET/HEAD）：启用 CORS 白名单 +
Access-Control-Allow-Origin $cors_origin+ 允许预检缓存 -
写接口（POST/PUT/DELETE）：禁用
Access-Control-Allow-Credentials；要求携带X-CSRF-Token；用if ($request_method ~ ^(POST|PUT|DELETE)$) { ... }触发额外校验 -
登录/令牌接口：完全关闭跨域响应头，或仅允许同源（
add_header 'Access-Control-Allow-Origin' '$http_origin'仅当$http_origin与$host匹配时）
