为什么需要Access-Control-Expose-Headers?

Bla*_*ski 64 cors

我正在寻找具体的安全原因,为什么添加它.当我实施cors并且可以看到所有标题被返回但我无法通过javascript访问它时,这是一个WTH时刻.

mon*_*sur 84

CORS以这样的方式实现,即它不会破坏在CORS之前,同源的世界中​​做出的假设.

在CORS之前的世界中,客户端可以触发跨源请求(例如,通过脚本标记),但它无法读取响应头.

为了确保CORS不会破坏这一假设,CORS规范要求服务器为客户端提供显式权限以读取这些标头(通过Access-Control-Expose-Headers标头).这样,未经授权的CORS请求就像在CORS之前的世界中那样.

  • 我发现这个链接是这个答案的一个很好的例子:https://fetch.spec.whatwg.org/#example-cors-with-response-header (2认同)
  • 换句话说,“Access-Control-Expose-Headers”根本不是为了安全,而是为了兼容性?没有我们使用 Access-Control-Expose-Headers 来缓解的攻击吗? (2认同)

Tri*_*hak 8

以下是需要 Access-Control-Expose-Headers 的原因:

Access-Control-Expose-Headers(可选)- XMLHttpRequest 2 对象有一个 getResponseHeader() 方法,该方法返回特定响应标头的值。在 CORS 请求期间, getResponseHeader() 方法只能访问简单的响应标头。简单的响应头定义如下:

  • 缓存控制
  • 内容语言
  • 内容类型
  • 过期
  • 最后修改
  • 编译指示

如果您希望客户端能够访问其他标头,则必须使用Access-Control-Expose-Headers标头。此标头的值是以逗号分隔的要向客户端公开的响应标头列表。

如需更多参考,请深入链接https://www.html5rocks.com/en/tutorials/cors/

快乐编码!!


syn*_*tel 5

这是一个很好的问题。浏览http://www.w3.org/TR/cors/#simple-response-header,您会想要或需要这样做的原因并不明显。

CORS 规范非常重视这样一个想法:您必须进行预请求握手,其中客户端请求某种连接类型,服务器响应它会允许它 - 所以这可能只是其中的另一个方面。

默认情况下,内容长度不是允许的标头,所以我遇到了同样的问题(后来当我需要访问 WebDAV 并且必须修改允许的参数时).. CORS 确实没有多大意义(对我来说) )首先,所以如果它的大部分内容是反复无常的,我不会感到惊讶。

  • CORS 让人感觉反复无常,正是因为规范作者仔细考虑了它。CORS 必须启用跨域请求,同时仍保护浏览器的同源策略。正是需要平衡这两种(有时是相反的)力量,使得 CORS 规范难以理解。 (4认同)