CORS已允许所有源（*）且预检正常，为何POST带origin头返回403？

按照触发概率从高到低排列，完全匹配你当前的现象特征：

1. 链路中间件执行顺序配置错误 #

• 这是最高发的同类问题诱因：配置CORS处理逻辑时，将其挂载在权限校验、CSRF防护等安全拦截逻辑的链路之后，而非最前置的执行节点。常见场景包括：
  • Nginx、API网关场景下，在最前置的路由判断中配置了Origin/Referer校验规则，校验不通过直接返回403，后续location块里配置的CORS响应头逻辑根本不会被执行
  • 后端框架场景下，CORS模块的注册顺序在鉴权、CSRF防护模块之后，安全校验逻辑先于CORS规则执行
• 对应的现象匹配逻辑：
  • 预检OPTIONS请求通常不会触发鉴权、CSRF类规则校验，网关层会直接放行返回200，带上CORS响应头
  • 实际POST请求携带Origin头走到安全校验逻辑时，会被判定为“外部跨域来源的非法请求”直接返回403，根本不会走到真正的业务处理环节
  • 去掉Origin头后，请求不会被识别为跨域流量，安全校验逻辑会默认其为合法的内部请求直接放行，和你观察到的现象完全一致

2. 安全防护规则对跨域请求的误拦截 #

• 云服务商WAF、主机自带的CSRF防护规则，默认会将携带Origin头的POST请求识别为潜在的跨站伪造攻击，直接返回403阻断流量。
• 对应的现象匹配逻辑：
  • 大部分防护规则会提前把跨域预检的OPTIONS请求标记为合法的浏览器跨域流程，直接放行不拦截
  • 实际POST请求携带Origin头时，会触发CSRF规则的判定逻辑，但规则未做精细化区分，没有将正常业务的跨域请求纳入白名单
  • 移除Origin头后，请求失去跨域伪造的特征标识，规则直接放行

3. 通配源配置与凭据规则的不兼容 #

• CORS规范明确规定：如果请求需要携带Cookie、Authorization头这类身份凭据，Access-Control-Allow-Origin 绝对不能配置为通配符*，必须精确匹配请求携带的Origin值。
• 部分CORS模块、安全网关的逻辑是：检测到请求携带Origin头，同时配置了通配源，就会判定为不合法的CORS配置，直接返回403，哪怕预检请求已经返回了200。

4. CORS匹配逻辑的通配符实现缺陷 #

• 部分老旧版本的框架CORS插件、自研网关的CORS逻辑存在bug：配置为*时，没有实现通配匹配的逻辑，而是要求请求携带的Origin值必须和配置的字符串严格相等。
• 只要请求的Origin值和字面上的*不匹配，模块就会直接返回403，不会返回正常的业务响应。

• 检查403响应的返回体：如果返回体为空、是固定的拦截提示页，而非业务接口返回的自定义错误信息，即可确定拦截发生在网关/中间件层，而非后端业务逻辑
• 逐次移除请求头测试：保持Origin头不变，依次移除Cookie、Authorization、自定义请求头，逐步定位是哪类请求头触发了拦截规则
• 调整中间件顺序：将CORS处理逻辑调整到所有安全校验、权限判断逻辑的最前置位置，确保CORS规则匹配完成后，再走后续的业务校验流程

注：你观察到的“移除Origin头请求正常”的特征，已经可以完全排除后端业务接口本身的权限配置问题，所有拦截逻辑都发生在CORS规则处理环节。

内容的提问来源于stack exchange，提问作者Ullaakut