【テクニカル・上級編】Cross-Origin Opener Policy (COOP)とCross-Origin Embedder Policy (COEP)による分離 – アプリケーションセキュリティ & 安全な開発防御ガイド

メモリの深淵とブラウザの限界：COOP/COEPが守る「隔離された聖域」

かつて、ブラウザのセキュリティモデルは「Same-Origin Policy (SOP)」という一本の防波堤で守られていた。しかし、Spectreに代表される投機的実行（Speculative Execution）の脆弱性が発覚して以来、CPUのキャッシュレイヤーという「物理的な現実」を前に、ソフトウェアレベルの論理境界線は無力であることを私たちは思い知らされた。

アプリケーションセキュリティの現場において、XSS（クロスサイトスクリプティング）はもはや単なる「スクリプトの注入」ではない。攻撃者は、XSSを足がかりに隣接するブラウザコンテキストのメモリ領域を覗き見（Side-Channel Attack）しようとする。ここで登場するのが、COOP (Cross-Origin Opener Policy) と COEP (Cross-Origin Embedder Policy) という、現代のWebアーキテクチャにおける「隔離の聖域」だ。

—

1. なぜ「論理的な境界」だけでは不十分なのか

XSSのペイロードが実行された際、攻撃者が狙うのは単なるクッキーの窃取だけではない。window.opener を介したクロスオリジン間の通信や、SharedArrayBuffer を利用したメモリ情報の読み出しが鍵となる。

Spectre攻撃は、CPUの分岐予測ミスを利用して、本来アクセスできないはずのキャッシュメモリの内容を読み取る。これがWebブラウザ上で行われると、同一のプロセス（あるいは同じサイトとして扱われるグループ）内に存在する機密情報が、微細なタイミング差（クロック計測）を通じて漏洩する。

COOP/COEPは、この「同居」を物理的に断ち切ることで、ブラウザのプロセスモデルを強制的に分離（Process Isolation）させる。これが、現代のWebアプリケーションにおける必須のセキュリティ要件だ。

—

2. COOP/COEPの実装：ブラウザを「隔離」する設定

これらのヘッダーを導入する際、最大の壁は「既存のサードパーティコンテンツとの互換性」だ。厳格に設定すればするほど、CDN経由の画像や外部広告SDKは動かなくなる。ここがエンジニアの腕の見せ所であり、泥臭い検証が必要な箇所だ。

推奨されるヘッダー構成

最高レベルのセキュリティを確保するための設定例を以下に示す。

1. COOP: ドキュメントを他のオリジンから分離し、window.openerとの関係を断つ
Cross-Origin-Opener-Policy: same-origin

2. COEP: 許可されたリソースのみを読み込み、クロスオリジンからのデータ混入を防ぐ
Cross-Origin-Embedder-Policy: require-corp

実務上のポイント：COOP-Report-Only と COEP-Report-Only

いきなり本番環境へ適用するのは自殺行為だ。まずはレポートモードで、どのリソースがブロックされるかを収集せよ。

/ Reporting APIの設定例: 違反をエンドポイントへ送信 /
{
“group”: “csp-endpoint”,
“max_age”: 10886400,
“endpoints”: [{ “url”: “https://security-logs.example.com/report” }]
}

—

3. 生成AI時代のプロンプト・インジェクションと隔離の相乗効果

今、我々が直面している最大のリスクは、LLM（大規模言語モデル）を組み込んだアプリケーションへの「プロンプト・インジェクション」だ。AIが外部APIを呼び出す際、その出力が攻撃者によって制御されたWebページに埋め込まれる可能性がある。

もしAIの出力するHTMLに攻撃コードが含まれ、それがユーザーのブラウザで実行された場合、COOP/COEPが未設定であれば、攻撃者はAIが保持するトークンや内部状態にまでアクセスを試みるだろう。

ガードレイルの設計論：

  • サンドボックス化: LLMの出力をレンダリングする際には、sandbox属性付きの