[109] Origin: ヘッダーは、 当該要求を行う fetch の実行元の起源originを表すものです。

仕様書

構文

[299] 欄値は、 起源または null です >>290。

[300] 起源は、URL scheme、://、ホスト、 :、ポートで構成され (: 以降は省略可能) >>290、 起源のASCII直列化を表します。

[301] null は、三項組で表されない起源を表します。 小文字でなければなりません。

  1. |
    1. =
      1. URL scheme
      2. ://
      3. ホスト
      4. ?
        1. :
        2. ポート
    2. null

[113] 利用者エージェントは任意の要求に Origin: 欄を含めて構いません。 >>21

[114] 一つの要求に複数の Origin: 欄を含めてはなりません。 >>21

[115] 複数含まれている場合に鯖がどう解釈するべきかは規定されていません。

null

[117] 値 null は3項組で表せない起源である時に使われます。

[116] RFC 6454 は、「プライバシー重視privacy-sensitive」な文脈では値 null を送信しなければならない >>21 としていました。 具体的に何が「プライバシー重視」な文脈かは Origin: 欄の仕様としては決めていませんが、 応用ごとに決めることもできます >>21。

空文字列

[142] HTML の定義に従えば起源のASCII直列化が空文字列になることもありますが、 その場合 Origin: の値をどうするべきかは不明確です。

[196] >>195 によれば Firefox では空文字列が null の変わりに使われることになっています。 古い仕様ではそうだったのかもしれません。

文脈

[50] Webブラウザーの fetch アルゴリズムは、 送信するHTTP要求の多くに、 HTTPヘッダー Origin: を付与します。

[51] 要求Originヘッダーの追加append a request `Origin` headerは、 要求について、 次のようにします。 >>49

  1. [53] 直列化起源を、 要求について要求起源を直列化した結果に設定します。
  2. [54] 要求のresponse taintingがcorsか、 要求のモード要求モードが websocket の場合、
    1. [55] 要求のヘッダーリストに、 Origin/直列化起源を末尾に追加します。
  3. [56] それ以外の場合で、 要求のメソッド要求メソッドが GET でも HEAD でもない場合、
    1. [58] 要求の参照元ポリシーにより、
      no-referrer
      直列化起源を、 null に設定します。
      no-referrer-when-downgrade, strict-origin, strict-origin-when-cross-origin
      1. [59] 要求の起源が項組起源で、 要求の起源のschemeURL schemeが https で、 要求の現在URLのschemeURL schemeが https でない場合、
        1. [60] 直列化起源を、 null に設定します。
      same-origin
      1. [61] 要求の起源が要求の現在URLの起源と同じ起源でない場合、
        1. [62] 直列化起源を、 null に設定します。
    2. [57] 要求のヘッダーリストに、 Origin/直列化起源を末尾に追加します。
[297] 互換性の問題からすべての要求には含まれません >>290。[42] プロキシに接続するための CONNECT には含まれません。

[298] Webブラウザーなど同一起源ポリシーで管理されたクライアントからの要求には Origin: ヘッダーが含まれますが、 それ以外の要求には普通は Origin: ヘッダーは含まれません。

[296] 要求メソッドが GET でも HEAD でもない要求や、 WebSocket接続の確立の要求、 CORS を使った他の起源への要求に含まれます >>290。

[308] fetch において、Originヘッダー省略フラグomit-Origin0header flagが未設定の時、 HTTP要求に Origin: ヘッダーが設定されます >>307。

[28] 初期値は未設定です >>306。

処理

CSRF 対策

[37] サーバーは、 CSRF 対策のためにこのヘッダーを使うことができます。

[38] Origin: ヘッダーの値がサーバーの想定する起源でなければ、 不当な起源からの要求であり、 CSRF 攻撃のおそれがありますから、 要求を拒否することとできます。

CORS

[36] サーバーは、 CORS のためにこのヘッダーを使うことができます。

[119] RFC 6454 では鯖による解釈の方法は特に規定されていませんでした。

[214] CORS では別起源への要求に対する鯖 (資源) での処理モデルが規定されており、 その中で Origin: の処理方法も規定されています。 Origin: に関する部分だけを抜き出すと、次の通りです。

DNS による攻撃

[210] 鯖側では Origin: が要求元として適切な起源かどうかチェックすることになりますが、 Host: をチェックしておかないと攻撃者が不正なドメイン名を当該鯖に結びつけることで意図せぬ要求を受理させることができるとされています。

[211] 例えば corp.example と corp.invalid があるとします。 corp.example が corp.example に cross-origin request を行い、 Origin: corp.example と送ります。この時 corp.invalid またはネットワークが不正にこの要求を corp.example に送りつけさせることができます。すると corp.example は自身からの要求を (意図せず) 受け取ることになります。 corp.example 側で Host: をチェックすれば、利用者エージェントが本当は corp.invalid に宛てて送ろうとしていたことを認識でき、 不適切な要求として処理できます。 (cross-origin request には HTTPS のような安全な接続を使うとより安全になります。) >>212 4.

歴史

[22] 例によって W3C や IETF で政治的なごたごたに巻き込まれて必要以上に長くかかっています。 RFC になるよりずっと先に Webブラウザーで実装が進みました。

[1] Cross-Site Request Forgery ( 版) http://crypto.stanford.edu/websec/csrf/

[2] Origin Header for CSRF Mitigation ( 版) http://crypto.stanford.edu/websec/specs/origin-header/

[3] HTML5 のナビゲーションの算法に組み込まれたみたいです。。。

[4] (X)HTML5 Tracking ( 版) http://html5.org/tools/web-apps-tracker?from=2668&to=2669

[5] ACTION-96: Origin removal (Henri Sivonen 著, 版) http://lists.w3.org/Archives/Public/public-html/2009Jan/0210.html

IETF

[6] draft-abarth-origin-00 - The HTTP Origin Header ( 版) http://tools.ietf.org/html/draft-abarth-origin-00

[7] (X)HTML5 Tracking ( 版) http://html5.org/tools/web-apps-tracker?from=4010&to=4011

[8] IRC logs: freenode / #whatwg / 20090821 ( 版) http://krijnhoetmer.nl/irc-logs/whatwg/20090821#l-235

[9] Security/Origin - MozillaWiki ( 版) https://wiki.mozilla.org/Security/Origin

[20] The HTTP Sec-From Header draft-abarth-origin-01 の頃は Sec-From: という名前が提案されていました。

[10] IRC logs: freenode / #whatwg / 20090929 ( 版) http://krijnhoetmer.nl/irc-logs/whatwg/20090929

[11] IRC logs: freenode / #whatwg / 20091002 ( 版) http://krijnhoetmer.nl/irc-logs/whatwg/20091002#l-620

[12] IRC logs: freenode / #whatwg / 20091204 ( 版) http://krijnhoetmer.nl/irc-logs/whatwg/20091204#l-293

[13] Security/Origin - MozillaWiki ( 版) https://wiki.mozilla.org/Security/Origin

[14] IRC logs: freenode / #whatwg / 20101109 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20101109#l-206

[15] drafts/origin.xml at master from abarth's ietf-websec - GitHub ( ( 版)) https://github.com/abarth/ietf-websec/blob/master/drafts/origin.xml

[16] IRC logs: freenode / #whatwg / 20110815 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20110815#l-134

[17] IRC logs: freenode / #whatwg / 20111022 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20111022

  • [21] RFC 6454 - The Web Origin Concept ( 版) http://tools.ietf.org/html/rfc6454#section-7

[107] Origin: 欄の構文は次のように定義されていました >>21。

   origin              = "Origin:" OWS origin-list-or-null OWS
   origin-list-or-null = %x6E %x75 %x6C %x6C / origin-list
   origin-list         = serialized-origin *( SP serialized-origin )
   serialized-origin   = scheme "://" host [ ":" port ]
                       ; <scheme>, <host>, <port> from RFC 3986

[108] RFC 6454 は、 SP 区切りのリストで複数の値を指定できるとしていました >>21。

[110] 要求がなされるまでに複数の起源が関わっている場合、 それをすべて列挙して構わない >>21 とされていました。

[111] 例えばリダイレクトが発生した時、大元の起源とリダイレクトを行った起源を列挙して構いません。

[112] しかし列挙の順序や鯖による解釈の方法については特に規定されていませんでした。

[118] 隣接する起源が同じidenticalであってはなりません。 そうなってしまう場合は片方だけ送信しなければなりません。 >>21

[191] fetch (>>126) の定義においてはリダイレクトの際に複数の値を Origin: を入れることは認められていません。ただし明示的に禁じられているわけではなく、 自然に読むと複数にはならないというだけなので、実際には禁止する意図は無いかもしれません。

[222] CORS (>>213) でも鯖側の処理モデルにおいて、 リダイレクトの時に複数の値が指定され得ることに言及はされているのですが、 利用者エージェント側の処理モデル上はそうなる場合が記述されていません。

[126] fetch 操作においては、起源が呼び出し元により明示された場合、 それを Origin: に使います。そうでない場合は「プライバシー重視」 な文脈として扱います。 >>125

[190] HTML や XHR の仕様上定義されたあらゆる HTTP 要求は fetch 操作経由で発行されるので、従ってこれを実装しているWebブラウザーからのあらゆる HTTP 要求は何らかの Origin: 欄を送出し得ることになります。 しかしよく読むといつ Origin: 欄を送出するべきかは RFC も HTML も XHR も規定していません。明示的な起源の指定無しに fetch が呼び出された時は null を送信しなければならない (>>126 + >>116) ということになっていますが、 これも無条件に送信することを強制する意図があるのかは怪しいです。

[193] 実際の Webブラウザーはフォームの提出や XHR などで Origin: を送出しますが、通常の文書の navigation などでは送出しないものもあります。

[18] Web Applications 1.0 r6941 Drop old origin definitions that no longer matter. ( ( 版)) http://html5.org/tools/web-apps-tracker?from=6940&to=6941

[19] Widget Access Request Policy ( ( 版)) http://dev.w3.org/2006/waf/widgets-access/#dfn-origin

[192] Origin Header Proposal ( ( 版)) http://people.mozilla.org/~bsterne/content-security-policy/origin-header-proposal.html

[194] 446344 – Implement Origin header CSRF mitigation ( ( 版)) https://bugzilla.mozilla.org/show_bug.cgi?id=446344

[197] Chromium Blog: Security in Depth: New Security Features ( ( 版)) http://blog.chromium.org/2010/01/security-in-depth-new-security-features.html

[198] Scheme/Host/Port: RFC 6454 and RFC 6455 ( ( 版)) http://www.schemehostport.com/2011/12/rfc-6454-and-rfc-6465.html

[199] javascript - Force Safari to include Origin header in jQuery GET request - Stack Overflow ( ( 版)) http://stackoverflow.com/questions/6417219/force-safari-to-include-origin-header-in-jquery-get-request

[204] AJAX - Introducing Cross-domain Request (XDR) ( ( 版)) http://msdn.microsoft.com/en-us/library/ie/dd573303(v=vs.85).aspx

[295] CORS における Origin: ヘッダーの利用については、 CORS 仕様書に規定がありました。

  • [213] Cross-Origin Resource Sharing ( 版) http://dvcs.w3.org/hg/cors/raw-file/tip/Overview.html#resource-processing-model
  • [221] Cross-Origin Resource Sharing ( 版) http://dvcs.w3.org/hg/cors/raw-file/tip/Overview.html#resource-sharing-check-0
  • [212] Cross-Origin Resource Sharing ( 版) http://dvcs.w3.org/hg/cors/raw-file/tip/Overview.html#security

[303] 著者が直接 Origin: を指定することは、 XHR で禁じられていました >>123。

[304] 現在では Fetch Standard で禁じられています >>302。
  • [123] XMLHttpRequest ( 版) http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#dom-xmlhttprequest-setrequestheader

WHATWG

[291] IETF の RFC 6454 の Origin: の定義は実際の Webブラウザーの実装と異なっていましたが、 IETF では手続き上改訂が難しい状況でした。

[292] Anne は、 WHATWG Fetch Standard において RFC 6454 を参照しつつもより正確な定義を含めました >>290。

[293] 2014年6月には URL Standard に URL の起源が追加され、 HTML Standard、URL Standard、Fetch Standard の3つの文書によって事実上 RFC 6454 は廃止されました >>310, >>311。

  • [311] Define URL's origin · c65766a · whatwg/url ( 版) https://github.com/whatwg/url/commit/c65766a674c6f4c3c521b6dc843f07c1fd23b4d2
  • [310] Fix origin xref mess; obsolete ORIGIN · d94f125 · whatwg/fetch ( 版) https://github.com/whatwg/fetch/commit/d94f125e97592c078e023d5490b65b4210ebe8dc
[294] 詳しくは起源の歴史の項を参照してください。

実装

[205] Origin: はまだ十分 interoperable に実装されていません。 別の起源への XHR+CORS POST では Chrome も Firefox も Origin: を送りますし、 XDR では IE も送りますが、フォームの POST で送るのは WebKit だけです。 また、同じ起源の時に送るのも Chrome だけです。

[289] Chrome は POST したページを再読み込みした時に Origin: を送らない(?)ようです。

関連

[124] Origin: を XMLHttpRequest などで著者が指定することはできません >>123, >>302。

[305] Origin: が指定された HTTP要求を、 CORS要求といいます >>306。

[309] RFC 6454 - The Web Origin Concept ( ( 版)) http://tools.ietf.org/html/rfc6454

[312] ( ( 版)) http://www.iana.org/assignments/message-headers/prov/access-control-allow-credentials

[23] Chrome 40 になって、 <meta name=referrer> で never や origin-when-crossorigin を指定すると Origin: null が送られるようになったみたいです。

[24] Web Applications 1.0 r4011 Synchronise with the latest Origin spec rules and semantics. ( 版) https://html5.org/r/4011

[25] Web Applications 1.0 r2525 CSRF mitigation -- add Origin header to all non-GET requests. ( 版) https://html5.org/r/2525

[27] Fix #91: rename force-Origin-header flag to omit-Origin; unset it whe… · whatwg/fetch@dfb8bff ( 版) https://github.com/whatwg/fetch/commit/dfb8bff8fd180009a549527220c304f098c932ed

[29] force-Origin-header flag set for no-cors requests · Issue #91 · whatwg/fetch ( 版) https://github.com/whatwg/fetch/issues/91

[30] Align with Fetch: force-Origin-header flag is now omit-Origin-header … · whatwg/xhr@bb19040 ( 版) https://github.com/whatwg/xhr/commit/bb19040865164a76a313b27dca1fcb21849b852a

[31] remove force-origin flag · w3c/beacon@5f1a2e7 ( 版) https://github.com/w3c/beacon/commit/5f1a2e7e9250ef7cce4b1222d8b87661110d8578

[32] Re: [referrer] Should referrer policy change value of the Origin header? (Mike West 著, 版) https://lists.w3.org/Archives/Public/public-webappsec/2016Feb/0006.html

[33] Should we send an Origin header for no-cors fetches? · Issue #225 · whatwg/fetch ( ()) https://github.com/whatwg/fetch/issues/225

[34] Consider setting omit-Origin-header-flag for same origin requests · Issue #31 · whatwg/xhr ( ()) https://github.com/whatwg/xhr/issues/31

[35] 1272302 – navigator.sendBeacon doesn't set Origin header for same-origin request ( ()) https://bugzilla.mozilla.org/show_bug.cgi?id=1272302

[39] Remove request's omit-Origin-header flag (annevk著, ) https://github.com/whatwg/fetch/commit/eb89fcd54bb39e81b11c569f6ad7ba615883f7b9

[40] Fetch: remove omit-Origin-header flag (annevk著, ) https://github.com/whatwg/html/commit/1d3dd5da311ce51eeaac027cb053cf482476099a

[41] Properly set the Origin header for WebSocket requests (nox著, ) https://github.com/whatwg/fetch/commit/406c5a60595c63d323693050b45d40823933e185

[26] IETF HTML5 Meeting March 2009 - W3C Wiki () https://www.w3.org/wiki/IETF_HTML5_Meeting_March_2009

[43] Fix Origin header and "no-cors" redirects behavior (annevk著, ) https://github.com/whatwg/fetch/commit/af45ce34d6943c2a31cfa1d306d6db3b24682634

[44] "no-cors" POST and 307/308 redirects · Issue #593 · whatwg/fetch () https://github.com/whatwg/fetch/issues/593

[45] Avoid using the CORS flag to reset request's origin in redirects by annevk · Pull Request #594 · whatwg/fetch () https://github.com/whatwg/fetch/pull/594

[46] Does Cloudflare support Cross-origin resource sharing (CORS)? – Cloudflare Support () https://support.cloudflare.com/hc/en-us/articles/200308847-Does-Cloudflare-support-Cross-origin-resource-sharing-CORS-

The Cloudflare CDN identifies cache items based on the Host Header + Origin Header +  Path and Query, which supports different objects using the same host header, but different origin headers

[47] Editorial: use %s ABNF notation (annevk著, ) https://github.com/whatwg/fetch/commit/e69e9c2b73b1aac124de47e8f32ee8979dfdb77a

[48] Make the Origin header honor Referrer Policy (outside of CORS) (JuniorHsu著, ) https://github.com/whatwg/fetch/commit/cc80ec58d24668413b7a3c7160d9b4d83ace7b20

[52] Make the Origin header honor Referrer Policy (outside of CORS) (JuniorHsu著, ) https://github.com/whatwg/fetch/commit/cc80ec58d24668413b7a3c7160d9b4d83ace7b20

[63] Let Origin header honor referrer policy for non CORS request by JuniorHsu · Pull Request #908 · whatwg/fetch () https://github.com/whatwg/fetch/pull/908

[64] Editorial: remove the CORS flag (annevk, , ) https://github.com/whatwg/fetch/commit/65138f3f20a80020e405c5a0fb3675abfd884013

[65] Remove the CORS flag by annevk · Pull Request #960 · whatwg/fetch () https://github.com/whatwg/fetch/pull/960