浏览器什么情况下发送Origin头信息？什么情况下浏览器将Origin设置为null？

Question

浏览器什么情况下发送Origin头信息？什么情况下浏览器将Origin设置为null？

httpfirefoxcorscross-domainfetch-api

85

如您从此Bugzilla线程（以及这个）所看到的，Firefox在POST请求中并不总是发送Origin头信息。RFC规定在某些未定义的“隐私敏感”情况下，不应发送。Mozilla在此处定义了这些情况。

我想知道是否只有在这些情况下Firefox才不会发送Origin头信息。据我所知，它还不会在跨域POST请求中发送它（尽管Chrome和Internet Explorer会），但我无法在文档中确认。是否有我遗漏的列出这些情况的地方？

- P Jones

这意味着为了防止攻击（尤其是CSRF），必须在后端处理它（即使使用CORS限制或同源策略），并禁用带有空原始标头的请求。 - Sahin

3个回答

5

对我而言，这发生在向本地主机的相对URL进行超级标准的表单POST时，似乎是由于存在以下情况所引发的。

<meta name="referrer" content="no-referrer">

在<head>中。将其更改为：

<meta name="referrer" content="same-origin">

似乎让Firefox更加愉快。

- andrewdotn

简单快捷，谢谢。 - Mohammad Hassani

谢谢，这帮了我找到它。在我的情况下，是Referrer-Policy no-referrer头导致Origin未设置（随后由于CORS被拒绝请求）。 - Dario Seidl

但是这仅适用于“referer”标头，而不是OP所谈论的“origin”标头。 - Kernel James

@KernelJames 这就是问题所在——你本以为这只会影响 referer，但当设置为 no-referrer 时，它还会导致浏览器发送 Origin：null。 - andrewdotn

3

_{我想在@sideshowbarker的优秀回答中添加一些信息，这已成为该主题最全面的来源，甚至被MDN链接。为了补充这个答案，我查阅了各种规范，并确定了自回答发布以来发生的一些变化。我还组织了信息，使其更易于阅读。此外，我使用了2023年初的WebArchive引用，而不是直接链接，因为规范可能会在未来发生变化。}

_{需要注意的是，@sideshowbarker和我的回答都应作为指南使用，因为浏览器维护者的实现、规则集和风格取决于他们的判断。}

_{将它们用作指南，如果您不确定，请务必进行测试。}

正如@sideshowbarker所提到的，各种规范将空的Origin头定义为：

不透明的来源
空来源

有了这个，我们可以通过规范来过滤出何时Origin头是null的：

GET或HEAD请求不允许跨源资源共享（CORS）或使用Websockets。对于所有其他使用same-origin，navigate或no-cors的请求模式，Origin标头被省略。一些Web API允许您指定mode，例如fetch，而其他API具有默认值，例如请求外部资源的<img>：^{1, 2}
- 通过URL请求其内容的任何嵌入式HTML元素。这些元素包括<link>，<script>，<img>，<audio>，<video>，<object>，<embed>和<iframe>。这些HTTP GET请求默认使用no-cors模式，除非在HTML元素上设置了crossorigin属性。请注意，<canvas>，<math>和<svg>不包括在内，因为它们无法从外部资源请求数据（例如使用src属性）。^{1, 2, 3}
- 任何GET或HEAD fetch()请求，其中mode选项的值为"navigate"，"same-origin"或"no-cors"。默认情况下，fetch()使用cors模式。^{1, 2}
- （旁注：XMLHttpRequest，与fetch不同，不允许设置mode并默认为cors，这意味着所有XMLHttpRequest都带有Origin标头。）⁴
Referrer-Policy设置为no-referrer，适用于不使用GET或HEAD方法且不使用cors或websocket的任何请求。⁵
网络错误的响应。404或500 HTTP响应状态不是网络错误，因为请求成功能够到达服务器。而是无效的协议、标头或服务器未发送响应。 ⁶
内容安全策略（CSP）阻止导航响应。术语{{link8："导航响应"}}指用户可以导航到的位置（通过<a>，<iframe>，window.location）或提交表单的位置（通过<form>）。fetch响应不被视为导航响应。⁷
URL模式：
- 使用data:方案创建的任何嵌入式内联文件⁸
- file:方案可能省略Origin标头（浏览器相关）⁹
- 参考资料：
  
  ^{¹ 在fetch规范中，除了GET或HEAD请求外，所有请求都会包含源（Origin）信息。}
  ^{² 在fetch规范中，使用cors或websocket模式时会带有源（Origin）头，但其他模式则不带。}
  ^{³ Request()构造函数的默认模式用于fetch和嵌入式HTML元素。}
  ^{⁴ 根据XHR规范，默认的XMLHttpRequest模式设置为cors。}
  ^{⁵ fetch规范在第3.1小节中提到了这一点。}
  ^{⁶ HTML规范规定，网络错误不应返回任何导航参数，包括来源（origins）。请参见21号（而非19.21号）小节。}
  ^{⁷ HTML规范规定，“Blocked” CSP响应会导致网络失败。请参见6.5号小节。其中CSP规范将其定义为网络错误，参见引用5。}
  ^{⁸ HTML规范规定，“data:”方案返回一个不透明的源（opaque origin）。}
  ^{⁹ URL规范规定，读者应决定如何处理“file:”方案，但建议使用不透明的源（opaque origin）。}
  ^{¹⁰ FileAPI规范列出了一些特定情况，这些情况下会使用不透明的源（opaque origin）。}
  ^{¹¹ URL规范列出了这些URL方案及其回退到“不透明的源（opaque origin）”的情况。}
  ^{¹² HTML规范指定在此iframe上下文中返回一个“不透明的源（opaque origin）”。请参见第5号小节。}
  ^{¹³ HTML规范规定，没有浏览上下文的Document具有“不透明的源（opaque origin）”。此外，HTML规范还规定使用createDocument()创建的Document也没有浏览上下文。}

- Advena

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- sideshowbarker · Accepted Answer

就实际要求的相关规范而言，答案有几个部分：

当浏览器必须将一个原点内部设置为一个被序列化为null的值时
当浏览器必须发送Origin头部时

以下是详细信息：

当浏览器必须将原点设置为一个被序列化为`null`的值时

HTML规范使用术语opaque origin并将其定义为“内部值”：

没有序列化时，它可以从中重新创建（按照原点的ASCII序列化，它被序列化为"null"），唯一有意义的操作是测试相等性

换句话说，无论HTML规范在哪里提到opaque origin，您都可以将其翻译为null。

HTML规范要求浏览器在以下情况下设置不透明原点或唯一原点：

根据Fetch规范，浏览器需要在以下情况下将origin设置为“全局唯一标识符”（基本上与“不透明起源”（即基本上意味着 null…）相同）：

跨来源重定向

URL规范要求浏览器在以下情况下设置不透明起源：

但请注意，仅因为浏览器在内部设置了一个不透明的来源（基本上是null），这并不一定意味着浏览器将发送一个Origin头。因此，请参阅本答案的下一部分，以了解浏览器必须发送Origin头的详细信息。

浏览器何时必须发送Origin头

浏览器在WebSocket请求和由fetch()或XHR调用发起的跨源请求中发送Origin头，或者由JavaScript库（axios、jQuery等）的ajax方法发起的跨源请求中发送Origin头，但不会在正常页面导航（即在浏览器中直接打开网页时）以及嵌入在网页中的资源（例如CSS样式表、脚本或图像）中发送（通常情况下）。

但这只是一个简化。除了WebSocket请求和跨源XHR/fetch/ajax调用之外，还有其他情况下浏览器会发送Origin头，并且在嵌入资源时也会发送Origin头。因此，下面是更详细的答案。

关于规范要求：规范要求在 WebSocket 请求和任何 Fetch 规范定义为 CORS 请求 的请求中，始终发送 Origin 标头：

CORS 请求 是包括 Origin 标头的 HTTP 请求。由于 Origin 标头“也包括所有方法不是 GET 或 HEAD 的请求”，因此无法可靠地确定其是否参与 CORS 协议。

因此，规范的意思是：在所有跨域请求中都会发送 Origin 标头，但对于所有 POST、PUT、PATCH 和 DELETE 请求，甚至对于同源的 POST、PUT、PATCH 和 DELETE 请求（根据 Fetch 的定义，它们实际上是“CORS 请求”——尽管它们是同源的），也始终会发送该标头。＊

浏览器必须发送Origin头的另一种情况是在设置了“CORS标志”的任何请求中，这在HTTP(S)请求方面是除非请求模式为navigate、websocket、same-origin或no-cors。

XHR 总是将模式设置为cors。但使用Fetch API时，这些请求模式是您可以使用init-object参数的mode字段设置到fetch(…)方法中的那些模式：

fetch("http://example.com", { mode: 'no-cors' }) // no Origin will be sent

字体请求始终将模式设置为cors，因此始终具有Origin标头。

对于任何带有{{link1：crossorigin属性}}（也称为“CORS设置属性”）的元素，HTML规范要求浏览器将请求模式设置为cors（并发送Origin标头）。

否则，对于嵌入资源 - 任何具有启动请求的URL属性的元素（<script src>、样式表、图像、媒体元素） - 请求的模式默认为no-cors；由于这些请求是GET请求，因此根据规范，浏览器不会为它们发送Origin标头。

当HTML表单元素发起POST请求时，这些POST的模式也默认为no-cors，就像嵌入资源的模式默认为no-cors一样。然而，与嵌入资源的GET请求不同的是，浏览器会发送Origin头信息给那些从HTML表单元素发起的no-cors模式的POST。

原因是，正如本答案中早先提到的，浏览器总是在所有POST、PUT、PATCH和DELETE请求中发送Origin头信息。

此外，为了完整和清晰：对于导航，浏览器不发送Origin头信息。也就是说，如果用户直接导航到一个资源——通过将URL粘贴到地址栏中，或者通过从另一个Web文档中跟随链接——那么浏览器不会发送Origin头信息。

＊_{Fetch规范中的算法要求浏览器对所有CORS请求发送Origin头，该算法如下：}

_{为请求request附加一个请求Origin头，请执行以下步骤：}

_{1. 让serializedOrigin成为使用request进行字节序列化的请求来源的结果。} _{2. 如果request的响应污染是"cors"或request的模式是"websocket"，那么

将Origin/serializedOrigin附加到request的头部列表中。} _{3. 否则，如果request的方法既不是GET也不是HEAD，

那么：[在这种情况下也发送Origin头]}

_{第二步要求在所有跨域请求中发送Origin头，因为所有跨域请求的响应污染设置为"cors"。}

_{但是第三步还要求在同源的POST、PUT、PATCH和DELETE请求中也发送Origin头（根据Fetch的定义，它们实际上是“CORS请求”——尽管它们是同源的）。}

_{以上描述了Fetch规范目前如何定义要求，这是由于2016年12月9日对规范进行的更改。在那之前，要求是不同的：}

• 先前同源POST未发送Origin

• 先前未在没有CORS的情况下从<form>进行跨域POST发送Origin

因此，Firefox的行为是描述问题的规范先前所要求的，而不是当前所要求的。

浏览器什么情况下发送Origin头信息？什么情况下浏览器将Origin设置为null？

当浏览器必须将原点设置为一个被序列化为null的值时

浏览器何时必须发送Origin头

参考资料：

当浏览器必须将原点设置为一个被序列化为`null`的值时