我什么时候应该在我的响应标头中真正将“Access-Control-Allow-Credentials”设置为“true”？

Question

MDN 表示，当必须在站点之间交换 cookie、授权标头或 TLS 客户端证书等凭据时，Access-Control-Allow-Crendentials 必须设置为 true。

考虑两个站点 A - https://example1.xyz.com，另一个是 B- https://example2.xyz.com。现在我必须从 A 向 B 发出 http Get 请求。当我从 A 请求 B 时，我得到了，

“请求中没有“Access-Control-Allow-Origin”标头 资源。因此不允许使用原点“http://example1.xyz.com” 访问。”

所以，我在 B 中添加以下响应标头

response.setHeader("Access-Control-Allow-Origin", request.getHeader("origin"));

这解决了同源错误，我可以向 B 请求。我应该何时以及为什么要设置

response.setHeader("Access-Control-Allow-Credentials", "true");

当我用谷歌搜索解决这个same-origin 错误时，他们中的大多数人建议同时使用这两个标题。我不清楚使用第二个Access-Control-Allow-Credentials。

1. 什么时候应该同时使用这两种方法？
2. 为什么要将Access-Control-Allow-Origin设置为从请求头获取的origin而不是通配符*？

请给我举个例子更好地理解它。

Answer 1

如果您希望请求也能够发送 cookie，则需要允许凭据。如果您需要授权传入请求，基于会话 ID cookie 将是一个常见原因。

设置通配符允许任何站点向您的端点发出请求。如果请求与您定义的白名单匹配，则设置允许来源很常见。一些浏览器会缓存允许响应，如果您也从另一个域请求相同的内容，这可能会导致请求被拒绝。

Answer 2

设置Access-Control-Allow-Credentials: true其实有两个作用：

• 如果包含凭据，则会导致浏览器 to actually allow your frontend JavaScript code to access the response
• 导致任何 Set-Cookie 响应标头 to actually have the effect of setting a cookie（否则将忽略 Set-Cookie 响应标头）

这些效果与设置 XMLHttpRequest.withCredentials 或 credentials: 'include' (Fetch API) 的效果相结合，导致 credentials (HTTP cookies, TLS client certificates, and authentication entries) 实际上被包含在请求中。

Fetch 规范中的https://fetch.spec.whatwg.org/#example-cors-with-credentials 有一个很好的例子

Answer 3

为什么要将Access-Control-Allow-Origin设置为从请求头获取的origin而不是通配符*？

除非你非常确定你在做什么，否则你不应该这样做。

以下情况实际上是安全的：

1. 您以这种方式设置响应标头的资源是旨在供所有人访问的公共站点或 API 端点，并且
2. 您只是没有设置可能使攻击者能够访问敏感信息或机密数据的 cookie。

例如，如果您的服务器代码设置 cookie 只是为了保存应用程序状态或会话状态以方便您的用户，那么获取 Origin 请求标头的值并反映/是没有风险的在Access-Control-Allow-Origin 值中回显它，同时发送Access-Control-Allow-Credentials: true 响应标头。

另一方面，如果你设置的 cookie 暴露了敏感信息或机密数据，那么除非你真的确定你有其他东西被锁定（不知何故......）你真的想避免反映 Origin 回来在Access-Control-Allow-Origin 值中（无需在服务器端检查），同时还发送Access-Control-Allow-Credentials: true。

如果您这样做，您可能会暴露敏感信息或机密数据，从而使恶意攻击者可以获取这些信息。有关风险的说明，请阅读以下内容：

• https://web-in-security.blogspot.jp/2017/07/cors-misconfigurations-on-large-scale.html
• http://blog.portswigger.net/2016/10/exploiting-cors-misconfigurations-for.html

如果您发送 CORS 标头的资源不是一个旨在供所有人访问的公共站点或 API 端点，而是位于 Intranet 内或位于某个 IP 地址后面 -受限制的防火墙，那么您肯定真的想避免结合Access-Control-Allow-Origin-reflects-Origin 和Access-Control-Allow-Credentials: true。 （在 Intranet 的情况下，您几乎总是希望只允许特定的硬编码/列入白名单的来源。）