Question

首先让我说我理解CORS的概念，主要是它如何工作，但我有一个非常具体的问题，关于它是如何在微软的Web API中实现的。我在Global.ascx.cs文件中配置了CORS，如下所示：

var cors = new EnableCorsAttribute("https://example.com", "*", "*");
config.EnableCors(cors);

现在，当我在web api中使用标头Origin: https://example.com请求资源时，我得到一个包含标题Access-Control-Allow-Origin: https://example.com的响应，这是预期的。但是，当我请求具有不同Origin值的相同资源或完全没有该标头时，来自服务器的响应没有Access-Control-Allow-Origin标头。

这是理想的结果吗？或者服务器是否应始终使用Access-Control-Allow-Origin标题回复？

我问，因为我们已经让Veracode扫描了我们的代码库，他们说响应应该总是有标题Access-Control-Allow-Origin: https://example.com。根据我的理解，浏览器仍然会抛出No 'Access-Control-Allow-Origin' header is present on the requested resource标头是否有不同的来源或者标头根本不存在（并且我认为不公开允许的域将是首选解决方案）

此外，我知道我可以通过将此标题添加到我的web.config来显示标题：

<system.webServer>
  <httpProtocol>
    <customHeaders>
      <add name="Access-Control-Allow-Origin" value="https://example.com" />
    </customHeaders>
  </httpProtocol>
</system.webServer>

但我真的只是想知道正确的实施是什么。

Answer 1

行为是设计的：

如果响应不包含Access-Control-Allow-Origin标头，则AJAX请求失败。具体来说，浏览器不允许该请求。即使服务器返回成功的响应，浏览器也不会将响应提供给客户端应用程序。

链接文章包含 CORS如何运作 部分的完整说明。

它还提供了浏览器发送预检请求时的信息以及如何在预检请求中启用标题Access-Control-Request-Method和Access-Control-Request-Header

Enabling CORS in Web API 2

规范还告诉我们，响应可能包含具有适当值的此标头以允许访问资源，但是如果资源不应该可用于客户端，则不必包含它

对CORS请求的HTTP响应可以包括以下标头：

Access-Control-Allow-Origin

通过在响应中返回Origin请求标头（可以是null）或*的文字值来指示是否可以共享响应。

Fetch standard

修改

来自W3 Recomendation的更明确，不允许从其他来源访问的资源不应包含Access-Control-Allow-Origin标头

对来自其他来源的应用程序（例如登录页面）无用的资源不应返回Access-Control-Allow-Origin标头。资源仍然必须保护自己免受CSRF攻击，例如要求在明确提供的请求内容中包含不可语量的令牌。此类资源的安全属性不受符合此规范的用户代理的影响。

Web API CORS实现

1 个答案: