[24] Webのセキュリティーモデルである同一起源ポリシーにおいて、 URL のドメイン等によって定まる資源の管理の単位を起源といいます。
[292] 起源は、URL scheme、ホスト、ポートなどによって決まる資源群の範囲であり、スクリプトなどが通常相互にアクセスできる領域を定めるものとなっています。
[310] 例えば http://www.example.com/hoge?aa に iframe で
http://www.example.org/fuga?bb が埋め込まれているとします。外側の Window
の起源は (http, www.example.com, 80) で、内側の Window
の起源は (http, www.example.org, 80) です。両者は異なる起源に属しますから、
一方のスクリプトから他方の DOM にはアクセスできません。
XMLHttpRequest起源[5] 起源 (origin) は、日本語で生成元、源泉、オリジンなどと訳されることもあります。 起源セキュリティーモデルはデータの出所に基づきセキュリティー的なデータの分離境界を定めるものであり、 「起源」の語にもこの“データの出所”のような意味があります。
[25] 起源は、 不透明起源または項組起源です >>135。
[8] 起源は、オブジェクトです。複数の箇所から同じ起源オブジェクトが参照されることがあります。 例えば複数の文書の起源が同じオブジェクトに設定される (起源を共有する) かもしれません。 その場合、当然ながら起源オブジェクトの編集はすべての参照箇所に影響します。
[47] 起源の複製が他の箇所に設定されることもあります。 これは複製時点の起源オブジェクトの構成値が同じ新しいオブジェクトを作ることを意味します。 その後一方の起源オブジェクトを編集しても、他方には波及しません。
[48] document.domain に値を設定すると、
起源オブジェクトが編集されることがあります。
[168]
新しい起源 (https, example.com, 443)
を作成し、
新しい起源 (https, example.com, 443)
を作成すると、
どちらも同じ起源を表すとしても、
一方を編集したときに他方には影響しないという意味で、
別のものです。
[226]
の改訂までは起源を他の起源の「別名」
とできるとされ、 document.domain の動作を説明するために用いられていましたが、
実際にはこの方法ではうまく説明できないことがわかり、改められました。
[2] 項組起源は、 scheme、 ホスト、 ポート、 ドメインで構成される項組です >>135。
[73] 項組起源オブジェクトは、 URL から作られます。 この元となる URL は URLの構文解析により正規化した結果なので、 起源の各項も、正規化済みの値になります。
[76] ポートは、整数か null です。既定のポート番号は使わずに null とします。
[39] HTTP などで起源をやり取りする必要がある時は、 URL の構文の部分集合によって直列化して表します (>>160)。
[40] 例えば http://www.example.com/foo/bar の起源は
(http, www.example,com, 80) の3項組によって表されます。
これを HTTP の Origin: 欄に含める時は、
http://www.example.com と表現します。
[3] 不透明起源は、 何らかの内部的な値で表されます >>135。 自身 (同じ起源オブジェクトやその複製として作られた起源オブジェクト) とは同じとみなされますが、それ以外とは異なるとみなされるものです。
[38] 不透明な識別子は利用者エージェントの外やスクリプトに露出することが無いので、 特定プロセス内の連番など任意の方法で決定できます。 他の起源と同じか異なるかさえ判断できれば、どんな方法で実装しても構いません。
[37] かつては、 不透明な識別子や大域的に固有な識別子と呼ばれていました。
[4] 不透明起源は、直列化できません。 null
や値なしなどとして表す場合もありますが、いったんそうするとどの不透明起源を表していたかはわかrなくなります。
[100] 仕様上はありませんが、実装上はそれ以外の起源も存在するかもしれません。
[104] file: は実装依存の独自形式の起源かもしれません。
[111] jar: が実装されている場合、独自形式の起源かもしれません。
[116] ブラウザー拡張が実装されている場合、項組起源かもしれませんし、 独自形式の起源かもしれません。
[140] テレビ業界は独自の URL scheme を使っており、 独自の起源を規定しています。
[150] 起源 A と起源 B が同じ起源であるとは、
次の手順が真を返すことを言います >>135。
[153] 同じ起源であるかどうかとは、基本的にはその対象の出自が同じサーバーであるかどうかを表しています。 Webセキュリティーの最も基礎となる関係です。
[107] 起源 A と起源 B が同じ起源ドメインであるとは、
次の手順が真を返すことを言います >>135。
[154] 同じ起源ドメインであるかどうかとは、同じ起源かどうかと多くの場合は一致しますが、
document.domain を考慮する点が異なっています。
[159] RFC 6454 の定義 (>>81) とは違って HTML Standard の定義はすべての場合を明確に規定していました。
[97] HTML Standard は追加データが同一であることも同じ起源の条件としていました。
[92] その後2016年3月に実効スクリプト起源との統合で改訂され、 同じ起源ドメインの比較方法も新たに規定されました。
[166] 他に、より緩い比較として、 同じサイトやschemeなしで同じサイトがあります。
[160] 起源の直列化 (文字列化) は、 1つのASCII文字列で起源を表現するものです。
[11] 不透明起源は null と表現されます。
直列化から元の起源を復元することはできなくなります。
[88] 起源起源の直列化 (旧ASCII直列化) は、 次のようにして得られる文字列です >>135。
[64] かつての RFC >>25 6.1. は、項組起源の場合にホストをそのまま出力するとしていました。
[65] かつての HTML Standard >>135 は、 項組起源の場合にホストに IDNA2003 ToASCII 演算を適用た結果を出力するとしていました。 この時、 AllowUnassigned と UseSTD3ASCIIRules の2つのフラグは設定した状態にすることとされていました。 またホストのいずれかの部品で ToASCII が失敗したら、 空文字列を返して直列化の手続きを停止することになっていました。
[141] HTML の定義に従えば、 LDHラベル化できない host だった場合に起源は空文字列によって表されることになります。 RFC の定義によれば空文字列になることはありません。
[66] HTML Standard の定義はその後 URL Standard の演算を参照する形となりました。
[67] 更に2016年3月には、 URL Standard に合わせて再度整理されました。 起源オブジェクトの作成時に使われた URL が既に URLの構文解析時点で ASCII 形に正規化されているため、ASCII直列化時点での演算は不要となっています。
[298] これは次の場面で使われています。
[69] ASCII直列化や Unicode直列化における項組起源起源の直列化は、
次のものを順に連結した文字列です >>135。
file: URL の起源の直列化[200] file: URL の起源は実装依存となっており (>>31)、
そもそもそれがどのような形で表されるのか不明確です。項組起源かもしれませんし、
不透明起源かもしれません。どちらでもない独自の形式かもしれません
(それが仕様上明確に認められているわけではありませんが)。
[201] 直列化の算法を素直に適用すれば、 null が得られるはずです。
しかし実装はそれ以外の値を使うことがあります。
[208] Access-Control-Allow-Origin: 欄では任意の起源を表す
* という特別な値も認められています。
[142] Blob URLの直列化では null の場合にかわりに実装定義の値が使われることになっています。
実際には完全に任意の値とできるわけではなく、項組起源と衝突しない値であることが期待されます。
[31] postMessage では、著者 (スクリプト)
が起源を指定するために URL (または特別な値 *、/) を使っています。
[120] IDN について、起源の定義が URI であることから起源の決定に ToASCII が必要となる場合があること、Unicode直列化を使う場面があることから起源の表記のために ToUnicode が必要となる場合があることにより、起源は IDNA に依存しています。
[122] RFC 上の起源の定義は IDNA2008 に拠っていますが、 IDNA2003 と IDNA2008 のどちらを実装するかによって結果が異なることへの注記もあります >>23 8.4。 HTML の起源の定義は IDNA2003 に拠っています。 現実のWebブラウザーが実装しているものは厳密にはどちらの仕様とも異なっています。
[296] ASCII直列化できないhostを含む起源は空文字列によって表されます。
[297] RFC 6454 の定義ではそのような起源の存在は考慮されていませんでした。
[136] 起源の直列化については、 RFC 6454 と HTML で微妙に定義が異なっていました。 >>25 6., >>135 [137] 元々 HTML にあった定義をコピーして IETF 版を作った時に政治的な理由か何かで書き換わったのでしょう。
[20] ポートの特別な値「手動上書き」の直列化の方法は規定されていませんが、 これを直列化しなければならない場面は無いと思われます。
[89] 起源起源の Unicode直列化は、 次のようにして得られる文字列です >>135。
[59] かつての RFC >>25 6.1. や HTML >>135 は、ホスト部分の直列化を次のように規定していました。
[60] HTML Standard の定義はその後 URL Standard の演算を参照する形に変更されました。
[68] 更に2016年3月に改めて URL Standard の規定に基づき整理されました。
[299] これは次の場面で使われていました。
[12] Unicode直列化は Mozilla では実装されていたものの、 他の Webブラウザーでは実装されていませんでした。 、ASCII直列化に統合される形で廃止されました。
[16] HOBA は、独自の直列化の方式を規定しています。 RFC 3986 URI から URL scheme、authority (hostname の意か?)、 port を連結したもの >>17 とされています。ただし既定のポート番号はなく、 必ず port を明示する必要があります >>17。
[170] サーバー側の実装では起源の一致条件の記述のためワイルドカードドメイン名が使えることがあります >>171。
[171] CORS configuration - Amazon Simple Storage Service, , https://docs.aws.amazon.com/AmazonS3/latest/userguide/ManageCorsUsing.html
[6] Web 上の色々なオブジェクトや概念に対して起源が定義されています。
XMLHttpRequest 起源[234] XMLHttpRequest起源は、基本的には
XMLHttpRequest文書の起源です。 >>232, >>231
つまりは XMLHttpRequest に対応する Window
オブジェクトの文書の起源です。
[230] ワーカーにあっては、 XMLHttpRequest 起源はスクリプトの起源です >>229。
[235] 匿名フラグが立っている場合は、大域的に固有な識別子です。 >>232
[236] XMLHttpRequest 起源は、 XHR で要求する資源が同じ起源かどうかの判定に使われます。また、
responseXML の Document の起源としても使われます
(文書の起源参照)。
[10] Web 上のいくつかの機能は、歴史的その他の理由で起源とは異なる適用範囲を持っています。 場合によってはセキュリティー上の問題となることがありますから、 注意が必要です。
Path により一部の path のみに限定されます。realm によって限定されます。また認証方式によってはホストをまたぐことも禁止はされていません。
domain="" 引数で起源とは無関係に保護空間を規定することができます。includeSubdomains を指定するとサブドメインにも適用されるようになります。document.domain を使うと元のサブドメインとポートの区別が失われます。[126] 同一起源ポリシーの適用対象外の項も参照してください。
[118] ブラウザー拡張、ウィジェット、アプリ内ブラウザー、 WebDriver といった類のものは必ずしも同一起源ポリシーに縛られず、 実装依存のセキュリティーモデルで管理されています。
[227] 起源 (や SOP) の概念は Netscape による JavaScript の開発以来、 次第に明確になってきましたが、長らく仕様として文書化されるには至りませんでした。 しかし2000年代の後半になり、ようやく RFC 6454 と HTML によってその仕様が正確に記述されることとなりました。
[81] 2つの起源が「同じ」である時、その時に限って同一です。 具体的には、
... と定義されています。 >>23 5.
[26] ある RFC 3986 URI の起源は次の手順により求められます >>23 4.。file なら、
実装定義の値を返して構いません。
[143] RFC 6454 では3項組だけでしたが、 HTML によれば更に場合によっては追加のデータを加えることができます。
[145] 追加のデータとしては、暗号化された接続を使っている時にサイトの証明書を用いることが想定されています。 途中で証明書が変化した時に、証明書も起源に含めることで、前後で別の起源として扱われるようになります。 >>135
[15] 実際にこの規定に従っている Webブラウザーが存在するのかは不明です。
[149] この規定は >>147 で追加されたもので、当時は URL の起源に関する規定において証明書を起源に含めても構わない状況が明記されていましたが、 >>148 で当該部分が RFC に委ねるとして削除され、しかし RFC には相当する規定が含まれなかったため、宙に浮いてしまっています。 (RFC にかわる URL Standard の定義にも、証明書は用いられていません。)
[14] 証明書を期限切れに伴い更新したり、鯖を構成するホストごとに異なる公開鍵を提供していたり >>13 する場合に起源が変わってしまって以前に保存したデータにアクセスできなくなったり、 フレーム間で通信できなかったりすると不便であり、再現しづらい互換性の問題が生じますから、 これを起源の構成要素に加えるのはあまり好ましくないのかもしれません。
[209] Cross-Origin Resource Sharing ( ( 版)) http://dvcs.w3.org/hg/cors/raw-file/tip/Overview.html#origin-request-header
[240] Errata for The Web Origin Concept ( (Anne van Kesteren 著, 版)) http://lists.w3.org/Archives/Public/www-archive/2012Jun/0001.html
[241] IRC logs: freenode / #whatwg / 20120619 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20120619#l-978
[245] IRC logs: freenode / #whatwg / 20120718 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20120718#l-432
[246] Web Applications 1.0 r7236 Recast how the origin handling is done for data: URLs in workers, and fix the shared worker origin handling for data: URLs so that you can actually reconnect to a data: shared worker. ( ( 版)) http://html5.org/tools/web-apps-tracker?from=7235&to=7236
[247] Web Applications 1.0 r7414 Require Cookies and Origin if you implement HTTP. ( ( 版)) http://html5.org/tools/web-apps-tracker?from=7413&to=7414
[250] [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters ( ( 版)) http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-December/038358.html
[251] Define Document's origin. In related news: we now have an HTML dependenc... · 922830c · whatwg/dom ( ( 版)) https://github.com/whatwg/dom/commit/922830c931d8b04d52e3482dfd9985cdcead43fe
[252] Define what origin and effective script origin are in various Document c... · 2f2cdf4 · whatwg/dom ( ( 版)) https://github.com/whatwg/dom/commit/2f2cdf4a29b7ed299c38f60eb35ed98918a7f439
[258] Cross-Origin Resource Sharing Standard ( ( 版)) http://fetch.spec.whatwg.org/
[259] IRC logs: freenode / #whatwg / 20130401 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20130401#l-615
[260] IRC logs: freenode / #whatwg / 20130416 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20130416#l-72
[261] https://github.com/whatwg/fetch/commit/05a8acd40d6f65c1a6dc830896cd8366a99d267d
[262] IRC logs: freenode / #whatwg / 20130418 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20130418#l-839
[263] IRC logs: freenode / #whatwg / 20130508 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20130508#l-108
[264] [websec] RFC6454 (Origin) vs URI schemes unlike "http" ( ( 版)) http://www.ietf.org/mail-archive/web/websec/current/msg01512.html
[265] Fetch Standard ( ( 版)) http://fetch.spec.whatwg.org/#http-origin-header
[266] [whatwg] Reorganizing and fixing "origin" ( ( 版)) http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-May/039599.html
[267] [whatwg] Reorganizing and fixing "origin" ( ( 版)) http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-May/039599.html
[268] Web Applications 1.0 r7873 Allow data: URLs to be given download= attribute names.]] ( ( 版)) http://html5.org/tools/web-apps-tracker?from=7872&to=7873
[270] [whatwg] Reorganizing and fixing "origin" ( ( 版)) http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-July/040050.html
[271] [whatwg] Fetch: Origin header ( ( 版)) http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-July/040196.html
[274] Bug 20701 – Location security restrictions are over-restrictive ( ( 版)) https://www.w3.org/Bugs/Public/show_bug.cgi?id=20701
[276] Web Applications 1.0 r8307 Fix the rules on what 'Origin' header to use when navigating to a resource in an <iframe>, <object>, <embed>, or <frame> element, so that the latter two are not forgotten. ( ( 版)) http://html5.org/tools/web-apps-tracker?from=8306&to=8307
[277] Bug 23005 – IDNA-related bits should instead reference terminology from http://url.spec.whatwg.org/ ( ( 版)) https://www.w3.org/Bugs/Public/show_bug.cgi?id=23005
[278] Web Applications 1.0 r8320 Clarify what it means for an image to have an origin ( ( 版)) http://html5.org/tools/web-apps-tracker?from=8319&to=8320
[279] Using Self-Hosted Objects - Facebook開発者 ( ( 版)) https://developers.facebook.com/docs/opengraph/using-objects/
[280] Flashと特定ブラウザの組み合わせでcross originでカスタムヘッダ付与が出来てしまう問題が未だに直っていない話 ( ( 版)) https://gist.github.com/mala/8857629
[281] 446344 – Implement Origin header CSRF mitigation ( ( 版)) https://bugzilla.mozilla.org/show_bug.cgi?id=446344
[282] Web Applications 1.0 r8262 Move the spec from a stack of incumbent scripts to a stack of script settings object. This should in theory have no concrete effects (though I may have changed some of the origin used for Web Workers started from document.domain-affected scripts that were called from other scripts with different original origins). ( ( 版)) http://html5.org/tools/web-apps-tracker?from=8261&to=8262
[290] IRC logs: freenode / #whatwg / 20140426 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20140426
[291] Bug 26152 – Would it not be better to define origin as identifier, tuple, or, alias? That alias is actually a link to another origin is not super clear this way. ( ( 版)) https://www.w3.org/Bugs/Public/show_bug.cgi?id=26152
[294] 2014年には URL の起源が URL Standard で定義されるようになり >>307、 実質的に URL Standard、Fetch Standard、HTML Standard によって RFC 6454 は廃止されました >>308, >>309, >>7。
[311] draft-nir-websec-extended-origin-02 - A More Granular Web Origin Concept ( ( 版)) http://tools.ietf.org/html/draft-nir-websec-extended-origin-02
[42] origin on HTMLHyperlinkElementUtils/Location is readonly · whatwg/html@2c97ff8 ( 版) https://github.com/whatwg/html/commit/2c97ff8e46a86911f621ee4303d0fc18ddcb9b2b
[45] Add ids to origin's types · whatwg/html@b870180 ( 版) https://github.com/whatwg/html/commit/b8701806808e6fc393a92207717a8bce72a91d1d
[46] Remove the origin aliasing concept · whatwg/html@438155d ( 版) https://github.com/whatwg/html/commit/438155d2a2255aa5ea84ae390744d8a8662ebec2
[51] Cleanup origin serialization · whatwg/html@5dcc1ee ( 版) https://github.com/whatwg/html/commit/5dcc1ee2124b5e54955845790bb47f5d1351d672
[77] Merge effective script origin into origin · whatwg/html@8a843f2 ( 版) https://github.com/whatwg/html/commit/8a843f2169a6864a3024c4329528dccb2051d275
[119] [css-cascade] Switch term to 'cascade origin'. Dfn the various origins. · w3c/csswg-drafts@9617cdd ( 版) https://github.com/w3c/csswg-drafts/commit/9617cdd5e117b4674e89b799fa437441f7fd80e4
[123] Editorial: clarify origin invariants · whatwg/html@e337726 ( 版) https://github.com/whatwg/html/commit/e337726ec3e20c418fb062fd3650c5830acd2b22
[125] Clarify the "no serialisation" statement for opaque origins ( (annevk著, )) https://github.com/whatwg/html/commit/8b69a96e95d2eea28ebf0134336bc75dccafc0ed
10.1.2.1 基本オリジン
localStorage API の動作において、受信機は HTML 文書のオリジンを以下と判断することを基 本とする。
放送伝送の HTML 文書
arib2://aid_[app_id].oid_[org_id]
※ [app_id]は、AIT における application_id を 16 進数表現した文字列。[org_id]は、AIT におけるorganization_idを16進数表現した文字列。いずれも先頭には"0x"を付加せず、 最小桁数で表現する。
通信伝送の HTML 文書
HTML 文書の URI に基づくスキーム、ホスト、ポート。
10.1.2.2 オリジンの読み替え
不揮発性記憶領域のうち放送領域にアクセスするキーが指定された場合、実行中のデータコンテ ンツが放送マネージドアプリケーションでかつ、アプリケーションバウンダリおよびパーミッショ ンビットマップによって放送領域へのアクセスが許されていれば、受信機は HTML 文書のオリジ ンを表 10-5 の通り判断するよう読み替える。アクセスが禁止されているコンテンツでは、 SecurityError 例外が発生し、メソッドの動作は行われない。つまり、放送マネージドアプリケー ションが各放送領域にアクセスできるかどうかは、HTML 文書の URI に基づくスキーム、ホスト、 ポート、application_id、organization_id には影響されない。
一時記憶領域へのアクセスにおいては、HTML 文書のオリジンを ARIB STD-B62 第二編 3.3.5 に基づいて判断する。
キー名を引数に取らないメソッド(localStorage.key(), localStorage.clear())とプロパティ (localStorage.length)は、オリジン読み替えを行わない。つまり、その対象は基本オリジンの領 域のみとなる。これは、オリジン読み替えを行うか否かが、アクセスするアイテムのキー名によっ て判断されるためである。
document.domain 属性を書き換えた場合は、Web Storage 仕様の規定に基づき、それ以降の localStrorage オブジェクトは無効化され、関連するメソッドは動作しなくなる。
表 10-5 読み替え先オリジン
アクセス領域 読み替え先オリジン
Ureg arib://localhost (※1)
Greg arib://localhost (※1)
放送領域
放送事業者共通領域 arib2://bs_common
放送事業者専用領域 arib2://bid_[broadcaster_id].nid_[original_network_id]
視聴者居住情報領域 arib2://localhost
一般領域 読み替えしない
※1 ARIB STD-B62 第二編 3.3.5 に基づく。
※2 [broadcaster_id]は、選局中サービスの broadcaster_id を 16 進数表現した文字列。
[original_network_id]は、選局中サービスの original_network_id を 16 進数表現した文字 列。いずれも先頭に”0x”を付加せず、英字は小文字とし、最小桁数で表現する。
[144] Remove Unicode serialization of an origin (annevk著, ) https://github.com/whatwg/html/commit/59ebd9c094d9d532458a9ee61f307bf41bc70811
[151] ASCII serialization (mikewest著, ) https://github.com/w3c/webappsec-csp/commit/0b236a75ddd245d0512da28f2e11311622a07ddd
[152] Origins serialize to ASCII these days (annevk著, ) https://github.com/whatwg/dom/commit/fba2caf4be29c30e7e03010d5fce240a729e0bed
[156] Explicitly block opaque origins from requesting manifests (#638) (dominickng著, ) https://github.com/w3c/manifest/commit/c586cf0ba4923489fba995d72c638bc46b7ea33d
[157] Explicitly block opaque origins from requesting manifests by dominickng · Pull Request #638 · w3c/manifest () https://github.com/w3c/manifest/pull/638
[161] Suggest use of origin in public suffix warning (mozfreddyb著, ) https://github.com/whatwg/url/commit/0c6e51d2927dbfd2fcb6448795b3e1537b555728
[162] Use ASCII serialization for origins (#1151) (jungkees著, ) https://github.com/w3c/ServiceWorker/commit/a47c6d86c1436a4fff573d2a5da92b0e14891fa2
[164] Use ASCII serialization for origins by jungkees · Pull Request #1151 · w3c/ServiceWorker () https://github.com/w3c/ServiceWorker/pull/1151
[165] Use ASCII serialization for origins · Issue #1142 · w3c/ServiceWorker () https://github.com/w3c/ServiceWorker/issues/1142
[169] Add TAO check (npm1, , ) https://github.com/whatwg/fetch/commit/9dd531988b04f4fadd43022a0613a90b42ce46d4