メモリの深淵を塞ぐ：COOP/COEPが現代のブラウザセキュリティにもたらす「分離」の真実
モダンブラウザのセキュリティモデルは、かつてない試練に直面している。我々が信じていた「同一オリジンポリシー（SOP）」という防壁は、SpectreやMeltdownといった投機的実行（Speculative Execution）を悪用するサイドチャネル攻撃の前に、その物理的な限界を露呈した。CPUのキャッシュラインに残された痕跡を読み取られるだけで、隔離されたはずのメモリ領域からシークレットが漏洩する。
この「物理層の脆弱性」をソフトウェアの論理レイヤーでどう封じ込めるか。その答えが COOP (Cross-Origin Opener Policy) と COEP (Cross-Origin Embedder Policy) だ。これは単なるヘッダーの設定ではない。ブラウザのプロセスモデルを物理的に分離し、「信頼できないもの」とのメモリ空間を強制的に断絶させるためのアーキテクチャ設計である。
1. COOP/COEPの核心：なぜ「分離」が必要なのか
Webアプリケーションにおいて、ブラウザは同一オリジンであればメモリ空間を共有しようとする。しかし、Spectreのような攻撃者は、この共有空間を利用して、悪意のあるサイト（攻撃者）が被害者のサイトのメモリをスキャンする。
これを防ぐ唯一の手段は、「プロセスレベルでの分離」だ。
- COOP: 自分のドキュメントを、別のオリジンからの「窓（window）」から隔離する。
same-originを設定することで、クロスオリジンなドキュメントとのブラウジングコンテキストグループを分離し、攻撃者からの直接的なメモリ参照を物理的に不可能にする。 - COEP: 読み込む外部リソースに対して「お前は本当に許可されているか？」を証明させる。
require-corpを設定することで、CORSやCOEPヘッダーを提示できないリソースの読み込みを拒絶する。
このペアは、ブラウザが crossOriginIsolated 状態になるための必要条件だ。これなしには、現代のブラウザが提供する最高精度のタイマー（performance.now() 等）や、SharedArrayBufferのような低レイヤー操作は封印されたままだ。
2. 実装のベストプラクティス：段階的導入の泥臭い戦術
いきなり本番環境でこれらを有効にすると、CDN上の広告や、サードパーティのAPIリクエストが一斉に停止する。現場でこれを導入する際は、以下のステップを踏むのが鉄則だ。
ステップ1：レポートモードで「何が壊れるか」を可視化する
まずは Report-Only ヘッダーを用いて、ブロックされるリソースを監視する。
段階的な導入のための監視設定
Cross-Origin-Opener-Policy: same-origin; report-to=”csp-endpoint”
Cross-Origin-Embedder-Policy: require-corp; report-to=”csp-endpoint”
ステップ2：堅牢なポリシーの適用
監視が完了し、必要なサードパーティリソースに Cross-Origin-Resource-Policy (CORP) ヘッダーを付与する等の調整が終われば、本番適用を行う。
Nginxでの設定例
メモリ空間を分離し、プロセスレベルでの孤立を強制する
add_header Cross-Origin-Opener-Policy same-origin always;
add_header Cross-Origin-Embedder-Policy require-corp always;
合わせて、読み込む外部リソースには必ずCORSかCORPが必要になる
以下のヘッダーを外部リソース提供元で設定してもらう必要がある
add_header Cross-Origin-Resource-Policy cross-origin always;
3. 生成AI時代の新たな脅威と「ガードレイル」の視点
現在、我々は大規模言語モデル（LLM）をWebアプリケーションに組み込むフェーズにいる。ここで注意すべきは、プロンプトインジェクションだけではない。生成されたコンテンツがブラウザ上で実行される際、それがサイドチャネル攻撃の媒介者となるリスクだ。
AIが生成したコードが万が一、サードパーティのスクリプトを介してサイドチャネル攻撃を仕掛けるロジックを注入されたとしても、COOP/COEPによる「分離」が機能していれば、攻撃者のスコープは極めて限定的なものに留まる。
セキュリティアーキテクトへの問い：
あなたのアプリケーションは、crossOriginIsolated 状態にあるか？
もし否であれば、ブラウザが提供する最高度の保護を放棄しているに等しい。たとえ耐量子暗号を導入して通信の秘匿性を担保したとしても、端末内のメモリが投機的実行によって「裸」になっている事実に目を背けてはならない。
最後に：泥臭い検証の重要性
ドキュメントを読むだけで満足してはいけない。ChromeのDevToolsを開き、window.crossOriginIsolated が true を返しているか確認すること。そして、ネットワークタブでサードパーティリソースが 403 エラーを吐いていないか、泥臭く追い続けること。
セキュリティとは、仕様書の中にではなく、パケットの断片とメモリの境界線上に存在する。我々が守るべきは、単なるデータではない。ユーザーのブラウザという、最後の防衛ラインそのものなのだ。
コメント