部分API服务是如何接受所有来源的Authorization头请求的？

你提到的「服务端不能向所有来源开放带Authorization头的凭证类请求」是对CORS规则的边界误读，二者的适用场景有明确区别：

• 仅当请求携带浏览器自动下发/携带的凭证（Cookie、缓存的HTTP基础认证信息、客户端SSL证书），且前端显式开启了withCredentials: true（fetch API对应配置为credentials: 'include'）时，服务端才不能返回Access-Control-Allow-Origin: *，必须同时返回Access-Control-Allow-Credentials: true且显式指定允许的来源，浏览器才会放行响应。
• 而Stripe、Square这类场景中，Authorization头里的Bearer token是开发者主动手动写入请求头的内容，不属于浏览器自动携带的凭证范畴，不受上述规则限制。

这类公开API服务的CORS配置通常如下：

• 固定返回Access-Control-Allow-Origin: *，允许所有来源的跨域请求
• 在Access-Control-Allow-Headers返回值中显式加入Authorization，放行跨域请求携带的该请求头
• 不需要返回Access-Control-Allow-Credentials: true，因为请求本身不涉及浏览器自动携带的凭证

普通业务服务很少采用这类配置，核心原因是两类场景的鉴权逻辑完全不同：

• 普通业务大多依赖Cookie存储的会话信息做鉴权，属于浏览器自动携带的凭证，必须遵守带凭证请求的CORS限制
• 支付平台的API密钥由开发者自行保管，恶意站点就算能跨域发请求，也拿不到合法的Bearer token，请求会直接被服务端鉴权拒绝，不存在安全风险。

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