HTML: The Living Standard
Edition for Web Developers — Last Updated 29 October 2025
Edition for Web Developers — Last Updated 29 October 2025
生成元は、ウェブのセキュリティモデルの基本的な通貨である。生成元を共有するウェブプラットフォーム内の2つの当事者が互いに信頼し、同一の権限を有すると仮定される。異なる生成元をもつ当事者は、互いに潜在的に悪意があると見なされ、互いから程度を変化させるよう隔離される。
たとえば、bank.example.comでホストされるExample Bankのウェブサイトは、charity.example.orgでホストExample CharityのウェブサイトのDOMを検査しようとすると、"SecurityError" DOMException が発生する。
生成元は次のいずれかである：
内部値であり、シリアライズされていないために再作成することができない（生成元のシリアライズごとに"null"としてシリアライズされる）。意味のある操作は、透過性のテストのみである。
A tuple consisting of:
生成元は、たとえば複数のDocumentオブジェクト間で共有できる。さらに、生成元は一般に不変である。タプルの生成元のドメインのみ、およびdocument.domain APIを介してのみ変更できる。
("https", "xn--maraa-rta.example", null, null)の シリアライゼーションは"https://xn--maraa-rta.example"となる。
次の表は、2つのタプル生成元が同一生成元および同一生成元ドメインである場合の例を示す。
| A | B | same origin | same origin-domain |
|---|---|---|---|
("https", "example.org", null, null) | ("https", "example.org", null, null) | ✅ | ✅ |
("https", "example.org", 314, null) | ("https", "example.org", 420, null) | ❌ | ❌ |
("https", "example.org", 314, "example.org") | ("https", "example.org", 420, "example.org") | ❌ | ✅ |
("https", "example.org", null, null) | ("https", "example.org", null, "example.org") | ✅ | ❌ |
("https", "example.org", null, "example.org") | ("http", "example.org", null, "example.org") | ❌ | ❌ |
スキームとホストは、スキーム（ASCII文字列）およびホスト（ホスト）のタプルである。
サイトは不透明な生成元またはscheme-and-hostである。
同一生成元および同一origin-domainの概念とは異なり、スキームレスで同じサイトおよび同じサイトの場合、ポートおよびドメインコンポーネントは無視される。
URLで説明される理由により、同一生成元チェックを優先して、可能な場合は同じサイトおよびスキームレスで同じサイトの概念を回避すべきである。
次の表は、2つのタプル生成元がスキームレス同一サイトおよび同一サイトである場合の例を示す。
wildlife.museum、museum、およびcomは公開サフィックスであり、example.comはそうではない：
| A | B | schemelessly same site | same site |
|---|---|---|---|
("https", "example.com") | ("https", "sub.example.com") | ✅ | ✅ |
("https", "example.com") | ("https", "sub.other.example.com") | ✅ | ✅ |
("https", "example.com") | ("http", "non-secure.example.com") | ✅ | ❌ |
("https", "r.wildlife.museum") | ("https", "sub.r.wildlife.museum") | ✅ | ✅ |
("https", "r.wildlife.museum") | ("https", "sub.other.r.wildlife.museum") | ✅ | ✅ |
("https", "r.wildlife.museum") | ("https", "other.wildlife.museum") | ❌ | ❌ |
("https", "r.wildlife.museum") | ("https", "wildlife.museum") | ❌ | ❌ |
("https", "wildlife.museum") | ("https", "wildlife.museum") | ✅ | ✅ |
("https", "example.com") | ("https", "example.com.") | ❌ | ❌ |
document.domain [ = domain ]セキュリティチェックのために使用される現在のドメインを返す。
サブドメインを削除する値に設定し、生成元のドメインを変更し、同じドメインの他のサブドメイン（同じことを行う場合）のページが互いにアクセスできるようにすることができる。これにより、ドメインの異なるホスト上のページが、互いのDOMに同期的にアクセスできるようになる。
サンドボックス化されたiframe、不透明な生成元をもつDocument、およびブラウジングコンテキストのないDocumentにおいて、セッターは"SecurityError"例外を投げる。crossOriginIsolatedまたはoriginAgentClusterがtrueを返す場合、セッターは何もしない。
document.domainセッターの使用を避ける。これは、同一生成元ポリシーが提供するセキュリティ保護を損なうものである。これは共有ホスティングを使用している場合に特に顕著である。たとえば、信頼できないサードパーティが同じIPアドレスだが異なるポートで HTTP サーバーをホストできる場合、document.domainセッターを使用した後に生成元を比較するときにポートが無視されるため、通常は同じホスト上の2つの異なるサイトを保護する同一生成元の保護が失敗する。
これらのセキュリティ上の落とし穴があるため、この機能はウェブプラットフォームから削除されるプロセスにある。（これは何年もかかる長いプロセスである。）
代わりに、安全な方法で生成元間で通信するために、postMessage() またはMessageChannelオブジェクトを使用する。
window.originAgentClusterこのセクションで説明されている方法で、このWindowがオリジンキーのエージェントクラスターに属す場合はtrueを返す。
セキュアなコンテキストで配信されたDocumentは、`Origin-Agent-Cluster` HTTPレスポンスヘッダーを使用して、オリジンキーのエージェントクラスターに配置するように要求することができる。このヘッダーは構造化されたヘッダーであり、その値は真偽値でなければらない。[STRUCTURED-FIELDS]
構造化されたヘッダーのtrueの値（すなわち、`?1`）ではない値は無視される。
このヘッダーを使用した結果は、document.domainを使用して同一生成元の制限を緩和しようとしても何も実行されない代わりに、WebAssembly.Moduleオブジェクトを生成元をまたいだDocumentに送信することができなくなることである（たとえ同じサイトであっても）。水面下で、この分離により、ユーザーエージェントは、プロセスやスレッドなどのエージェントクラスターに対応する実装固有のリソースをより効率的に割り当てることが可能になる。
ブラウジングコンテキストグループ内では、`Origin-Agent-Cluster`ヘッダーは、たとえ一方がヘッダーを送信し、他方が送信しない場合でも、同一生成元のDocumentオブジェクトが異なるエージェントクラスターで終わる原因にはならないことに注意する。
つまり、originAgentClusterゲッターは、同じブラウジングコンテキストグループ内の以前にロードされた同一生成元のページでヘッダーが省略されていた場合、たとえヘッダーが設定されていても、falseを返すことができるということである。同様に、ヘッダーが設定されていなくてもtrueを返すことができる。
不透明な生成元をもつDocumentは、無条件に生成元が分離されているとみなすことができる。その場合、ヘッダーは効果がなく、かつoriginAgentClusterゲッターは常にtrueを返すだろう。
同様に、エージェントクラスターのクロスオリジン分離モードが"none"ではないDocumentは、自動的にオリジンキーが設定される。生成元をまたいだ分離を達成するために使用される`Cross-Origin-Opener-Policy`および`Cross-Origin-Embedder-Policy`ヘッダーは、同じアドレス空間内のすべてのものがそこに存在することを保証することを目的としているため、`Origin-Agent-Cluster`ヘッダーは、リソースの割り当てに関する実装への追加のヒントとして有用であるかもしれない。しかし、それを追加しても、著者のコードに追加の目に見える影響はない。
オープナーポリシー値は、トップレベルブラウジングコンテキストにナビゲートされたドキュメントに対し、新しいトップレベルブラウジングコンテキストおよび、それに対応するグループの作成を強制できる。可能な値は次のとおり：
unsafe-none"これは（現在の）デフォルトであり、文書が別のオープナーポリシーを指定しない限り、文書がその前の文書と同じトップレベルブラウジングコンテキストを占有することを意味する。
same-origin-allow-popups"これは、前の文書が同じオープナーポリシーを指定しており、それらが同一生成元でない限り、文書の新しいトップレベルブラウジングコンテキストを強制的に作成する。
same-origin"これは、"same-origin-allow-popups"と同じように動作するが、作成される補助ブラウジングコンテキストは、同じオープナーポリシーを持つ同一生成元の文書を含める必要があることが追加される。さもなければ、オープナーに非公開で表示される。
same-origin-plus-COEP"これは"same-origin"と同じように動作するが、（新しい）トップレベルブラウジングコンテキストのグループの生成元をまたいだ分離を"logical"または"concrete"のいずれかに設定することが追加される。
"same-origin-plus-COEP"は`Cross-Origin-Opener-Policy`ヘッダーで直接設定することはできないが、`Cross-Origin-Opener-Policy: same-origin`と`Cross-Origin-Embedder-Policy` ヘッダー（値はクロスオリジン分離と互換）を一緒に設定した結果である。
noopener-allow-popups"これは、先行文書に関係なく、文書の新しいトップレベルブラウジングコンテキストを強制的に作成する。
noopener-allow-popups値を含めると、それが適用される文書とそのオープナーとの間のオープナー関係が切断されるが、それらの同一生成元の文書の間に強固なセキュリティ境界を作成しない。
同一生成元のアプリケーションによるその他のリスクには、次がある：
文書のコンテンツをフェッチする同一生成元リクエスト — Fetch Metadataフィルタリングによって緩和できる。[FETCHMETADATA]
同一生成元フレーミング - X-Frame-OptionsまたはCSP frame-ancestorsによって緩和できる。
JavaScriptでアクセス可能なcookie - すべてのcookieがhttponlyであることを確認することで緩和できる。
機密データへのlocalStorageアクセス。
サービスワーカーのインストール。
機密情報を公開するpostMessageまたはBroadcastChannelメッセージング。
同一生成元の文書に対してユーザーの操作を必要としない自動入力。
noopener-allow-popupsを使用する開発者は、機密性の高いアプリケーションが、localStorage、その他のクライアントサイドのストレージAPI、 BroadcastChannel、関連する同一生成元の通信メカニズムなど、他の同一生成元の文書にアクセスできるクライアントサイドの機能に依存しないようにする必要がある。また、サーバーサイドのエンドポイントが、応答コンテンツが同じオリジンのドキュメントに非ナビゲーションのリクエストに機密データを戻さないようにする必要もある。
Headers/Cross-Origin-Opener-Policy
Support in all current engines.
Documentの生成元をまたいだオープナーポリシーは `Cross-Origin-Opener-Policy`および`Cross-Origin-Opener-Policy-Report-Only` HTTPレスポンスヘッダーから派生する。このヘッダーは構造化されたヘッダーであり、その値はトークンでなければならない。[STRUCTURED-FIELDS]
妥当なトークンの値は、オープナーポリシー値である。トークンはまた、付属のパラメーターを持ってもよい。これらのうち、"report-to"パラメーターは、適切な報告エンドポイントを識別する妥当なURL文字列を持つことができる。[REPORTING]
ユーザーエージェントは、このヘッダーに不正値が含まれている場合、そのヘッダーを無視する。同様に、値がトークンとして解析できない場合、ユーザーエージェントはこのヘッダーを無視する。
Headers/Cross-Origin-Embedder-Policy
Support in all current engines.
埋め込みポリシー値は、リソース所有者からの明示的な許可なしに、生成元をまたいだリソースのフェッチを制御する3つの文字列の1つである。
unsafe-none"これはデフォルトの値である。この値を使用するとき、CORSプロトコルまたは`Cross-Origin-Resource-Policy`ヘッダーを通して明示的な許可を与えることなしに生成元をまたいだリソースをフェッチすることができる。
require-corp"この値を使用するとき、生成元をまたいだリソースをフェッチするには、CORSプロトコルまたは`Cross-Origin-Resource-Policy`ヘッダーを通してサーバーの明示的な許可が必要となる。
credentialless"この値を使用する場合、生成元をまたいだno-CORSリソースをフェッチすると、クレデンシャルが省略される。代わりに、明示的な`Cross-Origin-Resource-Policy`ヘッダーは必要ない。クレデンシャルを使用して送信されるその他のリクエストには、CORSプロトコルまたは `Cross-Origin-Resource-Policy`ヘッダーを介したサーバーの明示的な権限が必要である。
"credentialless"をサポートする前に、実装者は次の両方をサポートすることを強く勧める：
そうでなければ、攻撃者は、生成元をまたいだ分離機能を使用して、クライアントのネットワーク位置を利用して非公開リソースを読み取ることを可能にする。
エンベッダーポリシー値は、"credentialless"または"require-corp"である場合、生成元をまたいだ分離と互換性がある。
`Cross-Origin-Embedder-Policy`および`Cross-Origin-Embedder-Policy-Report-Only` HTTPレスポンスヘッダーフィールドは、サーバーが環境設定オブジェクトの埋め込みポリシーを宣言することを可能にする。このヘッダーは構造化されたヘッダーであり、その値はトークンでなければならない。[STRUCTURED-FIELDS]
妥当なトークンの値は、埋め込みポリシー値である。トークンはまた、付属のパラメーターを持ってもよい。これらのうち、"report-to"パラメーターは、適切な報告エンドポイントを識別する妥当なURL文字列を持つことができる。[REPORTING]
処理モデルは、トークンとして解析できないヘッダーの存在下ではオープンに失敗する（デフォルトで"unsafe-none"）。これには、与えられた応答に存在する`Cross-Origin-Embedder-Policy`ヘッダーの複数のインスタンスを組み合わせて作成された不注意なリストが含まれる。
`Cross-Origin-Embedder-Policy` | 最終埋め込みポリシー値 |
|---|---|
| No header delivered | "unsafe-none" |
`require-corp` | "require-corp" |
`unknown-value` | "unsafe-none" |
`require-corp, unknown-value` | "unsafe-none" |
`unknown-value, unknown-value` | "unsafe-none" |
`unknown-value, require-corp` | "unsafe-none" |
`require-corp, require-corp` | "unsafe-none" |
（同じことが`Cross-Origin-Embedder-Policy-Report-Only`にも適用される。）
サンドボックスフラグセットは次のフラグの0個以上の集合であり、これは潜在的に信頼されないリソースが持つ能力を制限するために使用される：
このフラグは、コンテンツが、サンドボックス化されたブラウジングコンテキスト自体（またはその中にさらにネストされたブラウジングコンテキスト）、補助ブラウジングコンテキスト（次に定義されるサンドボックス化された補助ナビゲーションブラウジングコンテキストフラグによって保護されている）、およびトップレベルブラウジングコンテキスト（サンドボックス化されたユーザー起動ブラウジングコンテキストフラグなしのトップレベルナビゲーション、および以下に定義されるサンドボックス化されたユーザー起動ブラウジングコンテキストフラグありトップレベルナビゲーションによって保護されている）以外のブラウジングコンテキストをナビゲートすることを防止するものである。
サンドボックス化された補助ナビゲーションブラウジングコンテキストフラグが設定されない場合、それにもかかわらず一定の場合における制限はポップアップ（新しいトップレベルブラウジングコンテキスト）を開くことができる。これらのブラウジングコンテキストは常に、1つの許可されたサンドボックス化されたナビゲーターを持ち、実際に移動するために作成したブラウジングコンテキストを許可する、ブラウジングコンテキストが作成されるときに設定を持つ。（そうでなければ、サンドボックス化されたナビゲーションブラウジングコンテキストフラグは、それらが開かれた場合であってもナビゲートされていくのを防ぐだろう。）
このフラグは、コンテンツが新しい補助ブラウジングコンテキストを作成するのを防ぐ。 たとえば、target属性やwindow.open()メソッドを使用する。
このフラグは、それらのトップレベルブラウジングコンテキストのナビゲートからコンテンツを防ぎ、かつそれらのトップレベルブラウジングコンテキストの遮断からコンテンツを防ぐ。サンドボックス化されたブラウジングコンテキストのアクティブウィンドウが一時的なアクティブ化を持たない場合にのみ考慮される。
ユーザーによるアクティブ化なしでサンドボックス化されたトップレベルナビゲーションブラウジングコンテキストフラグが設定されていない場合、コンテンツはそのトップレベルブラウジングコンテキストをナビゲートすることができるが、他のブラウジングコンテキストは、サンドボックス化されたナビゲーションブラウジングコンテキストフラグ、およびサンドボックス化された補助ナビゲーションブラウジングコンテキストフラグによって保護されたままである。
このフラグは、それらのトップレベルブラウジングコンテキストのナビゲートからコンテンツを防ぎ、かつそれらのトップレベルブラウジングコンテキストの遮断からコンテンツを防ぐ。サンドボックス化されたブラウジングコンテキストのアクティブウィンドウが一時的なアクティブ化を持つ場合にのみ考慮される。
ユーザーによるアクティブ化なしでサンドボックス化されたブラウジングコンテキストフラグと同様に、このフラグはトップレベルブラウジングコンテキストにのみ影響する。 設定されていない場合、他のブラウジングコンテキストが他のフラグによって保護されている可能性がある。
このフラグは、不透明な生成元にコンテンツを強制する。したがって、同一生成元から他のコンテンツにアクセスすることを防止する。
このフラグはまた、document.cookie IDL属性からの読み取りまたは書き込みをするスクリプトを防止し、localStorageへのアクセスをブロックする。
このフラグはフォーム送信をブロックする。
このフラグはPointer Lock APIを無効にする。[POINTERLOCK]
このフラグは、スクリプトの実行をブロックする。
このフラグは、自動ビデオ再生や自動フォームコントロールフォーカスなどの、自動的に切り替える機能をブロックする。
document.domainブラウジングコンテキストフラグこのフラグは、コンテンツがdocument.domainセッターを使用することから防ぐ。
このフラグは、コンテンツが作成する補助ブラウジングコンテキストがコンテンツのアクティブなサンドボックスフラグセットを継承するのを保証することで、そのコンテンツがサンドボックスをエスケープするのを防ぐ。
このフラグは、コンテンツが次の機能のいずれかを使用してモーダルダイアログを生成するのを防ぐ：
このフラグは、画面の向きをロックする機能を無効にする。[SCREENORIENTATION]
このフラグはPresentation APIを無効にする。 [PRESENTATION]
このフラグは、ハイパーリンクのダウンロードまたはダウンロードとして処理されるナビゲーションのいずれを介して、コンテンツがダウンロードを開始またはインスタンス化するのを防ぐ。
このフラグは、非フェッチスキームへのナビゲーションが外部ソフトウェアに渡されるのを妨げる。