ASP.NET CORS仅允许单个源访问配置失效问题咨询

为什么设置空允许源后Postman请求仍能正常处理 #

CORS是浏览器端实现的同源策略限制机制，而非服务端主动拦截请求的规则：

• 服务端的CORS配置仅负责在响应中添加Access-Control-*相关头，本身不会拒绝请求执行、也不会主动中断响应返回
• Postman、curl、服务端调用这类非浏览器场景，都不会实现同源策略校验，也不会根据CORS头丢弃响应，因此不管CORS如何配置，请求都会被正常处理返回
• 你设置的空允许源配置实际已生效：对应接口的响应不会返回Access-Control-Allow-Origin头，若从浏览器的其他域名下发起请求，浏览器会主动拦截响应并抛出跨域错误，但服务端逻辑已经执行完成了

用CORS实现「仅允许服务A访问服务B」的需求是错误选择 #

CORS的设计目标是限制浏览器端的跨站请求访问，无法阻止非浏览器场景的调用：不管是其他服务端主动请求，还是用Postman这类工具模拟请求，CORS都完全起不到拦截效果，和你预期的服务间访问控制需求不匹配。

正确的实现方案 #

你需要的是服务级别的访问控制，可根据部署场景选择以下方案：

• IP白名单限制：适合内网部署场景，给服务B添加全局中间件/在网关层配置，仅允许服务A的IP/IP段的请求通过，其他IP直接返回403
• 请求密钥校验：适合跨公网调用场景，服务A、B预先约定唯一密钥，服务A每次请求在Header中携带该密钥，服务B通过全局中间件校验密钥有效性，校验失败直接拒绝请求
• OAuth2.0 客户端凭证模式：适合多服务统一权限管控场景，服务A先向身份服务申请访问令牌，请求服务B时携带令牌，服务B校验令牌合法性后才允许访问
• 若使用K8s等容器编排平台，可直接配置网络策略（NetworkPolicy），限制只有服务A的Pod可以访问服务B的Pod，实现链路层的访问隔离

补充说明 #

你现有的CORS配置本身没有语法错误，只是使用场景不符合需求。AllowedHosts配置用于校验请求的Host头是否合法，默认未配置时允许所有Host，和当前问题无关联。

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