同一オリジンポリシーとサイト分離の信頼境界

同一オリジンポリシー（SOP）は「別オリジンの中身を読ませない」既定ルールです。ただし現代のブラウザは、SOP だけでなくサイトという別の単位や、Spectre 以降に追加された一連のヘッダで信頼境界を多層化しています。ここを正確に区別できると、CORS・COOP・COEP の使い分けが一本の筋で見えてきます。

オリジンとサイトは別の単位

混同されがちですが、オリジン（origin） とサイト（site） は粒度が違います。

• オリジン: scheme ＋ host ＋ port の3点組。SOP の基本単位。
• サイト: scheme ＋ eTLD+1（登録可能ドメイン）。ポートは無視し、ホストは登録ドメインまで丸める。

eTLD は Public Suffix List（PSL）で定義される「実効トップレベルドメイン」で、.com や .co.jp、github.io などが該当します。eTLD+1 はそこにラベルを1つ足した、ユーザーが登録できる最小単位です。

なぜ2つの単位が要るのか。SOP は「JS がレスポンスを読めるか」というデータアクセスの境界、サイトは「ブラウザがどこまでをひとまとまりとして扱うか」という運用・分離の境界だからです。後述のサイト分離（プロセス割り当て）や一部の Cookie 属性はサイト単位で動きます。

SOP が守る境界と、CORS による緩和

SOP の核心は、あるオリジンの JavaScript に別オリジンのレスポンス本文を読ませないことです。<img> や <script>、<link> での読み込み自体は許す一方、fetch の結果や <canvas> に描いた他オリジン画像のピクセルなど「中身の読み取り」を封じます。これがないと、ログイン状態の Cookie を伴って他サイトの機密を盗み読みできてしまいます。

正当な別オリジン通信を通すための緩和策が CORS です。サーバーが Access-Control-Allow-Origin を返すことで、ブラウザが「このオリジンには読ませてよい」と判断します。判定するのはブラウザで、フロントのコードでは消せません。詳細は CORS（オリジン間リソース共有） を参照してください。

サイト分離と Spectre — なぜ強化策が要るのか

CORS が緩和なら、COOP / COEP / CORP は逆向きの強化策です。背景には Spectre があります。Spectre は CPU の投機的実行を悪用し、同一プロセスのメモリを読み出すサイドチャネル攻撃です。つまり攻撃者のコードと機密データが同じプロセスに同居していること自体が危険になりました。

対策がサイト分離（Site Isolation） です。ブラウザは異なるサイトを別 OS プロセスに分け、クロスサイトのデータが同じアドレス空間に乗らないようにします。ここで分離の単位が「オリジン」ではなく「サイト」なのは、document.domain 操作など同一サイト内オリジン間の協調を壊さないための互換性配慮です。

ただしプロセス分離だけでは、SharedArrayBuffer のような高精度タイマーを構成できる機能を安全に提供できません。そこで「ページが自分のプロセスにクロスオリジンの汚染物を一切引き込んでいない」と保証するための仕組みが COOP/COEP です。

COOP / COEP / CORP の役割分担

3つのヘッダはレスポンスヘッダで、守る対象が異なります。

関係を整理すると、COEP は「読み込む側が、引き込むサブリソースに許可の証明を要求する」ポリシー、CORP は「読み込まれる側が、自分はどこに埋め込まれてよいかを宣言する」ポリシーです。COEP: require-corp 下では、各クロスオリジンサブリソースが Cross-Origin-Resource-Policy ヘッダ（または CORS）で明示的に許可を出していないと読み込めません。

HTTP/1.1 200 OK
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

HTTP/1.1 200 OK
Cross-Origin-Resource-Policy: cross-origin
Content-Type: image/png

crossOriginIsolated が意味するもの

COOP: same-origin と COEP: require-corp（または credentialless）が両方成立すると、そのトップレベルドキュメントは「クロスオリジン分離（cross-origin isolated）」状態になり、self.crossOriginIsolated が true を返します。これは「このページのプロセスにはクロスオリジンの汚染物が混入していない」という保証です。

この状態が満たされて初めて、以下のような強力すぎて Spectre に悪用され得る機能が解禁されます。

つまり crossOriginIsolated は単なるフラグではなく、「サイドチャネルで隣を盗み見られないことをブラウザが確認した」という証明書です。WebAssembly のスレッド機能やマルチスレッド処理を本気で使うには、この分離が事実上の前提になります。Service Worker を絡めた高度なオフライン構成でも同じ制約が効くため、設計時には PWA と Service Worker の制約とあわせて検討するとよいでしょう。

まとめ — 3つの境界を重ねて読む

整理すると、ブラウザの信頼境界は層になっています。SOP が「データを読ませない」既定の壁、CORS がその穴を開ける緩和、COOP/COEP/CORP が「プロセスに他オリジンを混ぜない」強化、そして crossOriginIsolated がそれらの達成を示す到達点です。粒度の面では、SOP と CORS はオリジン、サイト分離と一部 Cookie 判定はサイトで動くことを押さえておくと、挙動の食い違いに迷いません。認証情報を伴う通信の落とし穴は Cookie とセッション管理 と Web 認証の仕組み もあわせてどうぞ。