Access-Control-Allow-Credentials头作用是什么？仅配置ACAO为何不足？

为何仅配置Access-Control-Allow-Origin不足以满足跨域需求？ #

Access-Control-Allow-Origin只是CORS校验的基础规则，仅解决了「域名是否被允许跨域访问」的第一层校验，以下场景需要额外配置才能正常使用：

• 如果跨域请求需要携带Cookie、HTTP认证信息、客户端SSL证书等身份凭证，服务端必须同时返回Access-Control-Allow-Credentials: true，且Access-Control-Allow-Origin不能设为通配符*，必须明确指定匹配的域名，否则浏览器依然会拦截响应。
• 如果是非简单请求（比如请求方法为PUT/DELETE，或请求头携带自定义字段、Content-Type值不属于application/x-www-form-urlencoded/multipart/form-data/text/plain三类），浏览器会先发送OPTIONS预检请求，此时服务端还需要配置Access-Control-Allow-Methods、Access-Control-Allow-Headers匹配对应的请求方法和请求头，预检通过后才会发起实际请求，仅配置Access-Control-Allow-Origin会直接导致预检失败。
• 如果需要让前端JavaScript读取响应中的自定义响应头，还需要额外配置Access-Control-Expose-Headers，否则前端只能拿到浏览器默认暴露的几个基础响应头（如Cache-Control、Content-Type等），自定义头会被浏览器隐藏。

什么场景下会返回Access-Control-Allow-Origin: someDomain.com却不同时返回Access-Control-Allow-Credentials？ #

这类场景非常普遍，核心原因是对应跨域接口不需要调用方携带身份凭证：

• 公开无身份态的服务：比如公共静态资源（图片、开源JS/CSS库）、公开数据接口（天气查询、公共IP查询），这类接口无需识别用户身份，不需要接收Cookie，自然不需要添加Access-Control-Allow-Credentials头。
• 服务端主动禁止跨域请求携带身份凭证：为了降低CSRF攻击风险，故意不开通凭证允许规则，就算前端强行设置withCredentials: true，浏览器也会直接拦截响应，从机制上避免用户身份被冒用。
• 接口本身采用请求头/请求参数携带Token的方式做身份校验，完全不依赖Cookie传递身份信息，也就不需要开启Credentials支持。

为何允许来自可信域名的跨域GET请求，却仅在Cookie被携带时拦截响应？ #

这是浏览器为了平衡可用性和身份安全设计的规则：

• 不带Cookie的跨域GET请求属于匿名请求，就算允许访问也不会泄露用户在目标站点的私人数据，比如你在A站点调用B站点的公开天气接口，不需要登录态，也不会拿到你在B站点的个人信息，自然不需要额外限制。
• 一旦请求携带了Cookie，就意味着这个请求是「以用户在目标站点的登录身份」发起的，此时如果随便允许响应返回，会带来严重的安全风险：比如恶意网站可以偷偷调用你登录过的银行接口查询余额、甚至发起操作请求。就算Access-Control-Allow-Origin配置的是可信域名，也需要额外校验Access-Control-Allow-Credentials，确认服务端确实允许这个带身份的跨域请求，避免用户身份被滥用。
• 结合SameSite默认规则补充：默认SameSite=Lax下跨域POST请求本身就不会携带Cookie，跨域GET虽然允许携带，但有CORS的Credentials校验兜底，相当于两层安全防护，最大程度降低CSRF类攻击的风险。

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