このページは Cloud Translation API によって翻訳されました。

COOP と COEP を使用してウェブサイトを「クロスオリジン分離」を実現

COOP と COEP を使用してクロスオリジン分離環境を設定し、SharedArrayBuffer、performance.measureUserAgentSpecificMemory()、高解像度タイマーなどの強力な機能をより高い精度で有効にします。

Eiji Kitamura

注意: Chrome デスクトップの SharedArrayBuffer は、Chrome 92 以降でクロスオリジン分離を必要とします。詳しくは、Android 版 Chrome 88 とパソコン版 Chrome 92 での SharedArrayBuffer の更新をご覧ください。

更新

2022 年 6 月 21 日: クロスオリジン分離が有効になっている場合、ワーカースクリプトにも注意が必要です。説明をいくつか追加しました。
2021 年 8 月 5 日: JS Self-Profiling API は、クロスオリジン分離を必要とする API の 1 つとして言及されていましたが、最近の方向性の変更を反映して削除されました。
2021 年 5 月 6 日: 報告されたフィードバックと問題に基づき、クロスオリジン分離されていないサイトでの SharedArrayBuffer の使用を Chrome M92 で制限するようスケジュールを調整することにしました。
2021 年 4 月 16 日: クロスオリジン分離の条件を緩和するための新しい COEP 認証情報なしモードと COOP same-origin-allow-popups に関する注記を追加しました。
2021 年 3 月 5 日: SharedArrayBuffer、performance.measureUserAgentSpecificMemory()、デバッグ機能の制限を削除。Chrome 89 で完全に有効になりました。精度が向上する予定の performance.now() と performance.timeOrigin という今後の機能を追加しました。
2021 年 2 月 19 日: DevTools の機能ポリシー allow="cross-origin-isolated" とデバッグ機能に関する注記を追加しました。
2020 年 10 月 15 日: self.crossOriginIsolated は Chrome 87 から利用できます。これを反映して、self.crossOriginIsolated が true を返すと、document.domain は変更不可になります。performance.measureUserAgentSpecificMemory() のオリジントライアルが終了し、Chrome 89 でデフォルトで有効になります。Android 版 Chrome の Shared Array Buffer は Chrome 88 以降で利用可能になります。

一部のウェブ API は、Spectre などのサイドチャネル攻撃のリスクを高めます。このリスクを軽減するため、ブラウザはクロスオリジン分離と呼ばれるオプトインベースの分離環境を提供しています。クロスオリジン分離状態では、ウェブページは次のような特権機能を使用できます。

クロスオリジン分離状態の背後で利用可能になる機能。
API	説明
`SharedArrayBuffer`	WebAssembly スレッドに必要です。この機能は Android 版 Chrome 88 以降で利用できます。パソコン版は現在、サイト分離のサポートによりデフォルトで有効になっていますが、クロスオリジン分離状態が必要になり、 Chrome 92 でデフォルトで無効になります。
`performance.measureUserAgentSpecificMemory()`	Chrome 89 以降で利用できます。
`performance.now()`、`performance.timeOrigin`	現在、多くのブラウザで利用できますが、解像度は 100 マイクロ秒以上に制限されています。クロスオリジン分離では、解像度は 5 マイクロ秒以上になります。

クロスオリジン分離状態では、document.domain の変更も禁止されます。（document.domain を変更できると、同一サイトのドキュメント間で通信が可能になり、同一オリジンポリシーの抜け穴と見なされてきました）。

クロスオリジン分離状態を有効にするには、メインドキュメントで次の HTTP ヘッダーを送信する必要があります。

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

これらのヘッダーは、クロスオリジンドキュメントによる読み込みをオプトインしていないリソースや iframe の読み込みをブロックし、クロスオリジンウィンドウがドキュメントと直接やり取りすることを防ぐようブラウザに指示します。これは、クロスオリジンで読み込まれるリソースでオプトインが必要になることも意味します。

ウェブページがクロスオリジン分離状態にあるかどうかは、self.crossOriginIsolated を調べることで判断できます。

この記事では、これらの新しいヘッダーの使用方法について説明します。フォローアップ記事で、背景とコンテキストについて詳しく説明します。

注: この記事は、ブラウザプラットフォーム全体でより堅牢な方法で SharedArrayBuffer、WebAssembly スレッド、performance.measureUserAgentSpecificMemory()、または高解像度タイマーをより高い精度で使用できるようにウェブサイトを準備したい方を対象としています。

COOP と COEP をデプロイしてウェブサイトをクロスオリジン分離する

COOP と COEP を統合する

1. 最上位ドキュメントに `Cross-Origin-Opener-Policy: same-origin` ヘッダーを設定する

最上位のドキュメントで COOP: same-origin を有効にすると、同じオリジンのウィンドウと、ドキュメントから開かれたウィンドウは、同じオリジンで同じ COOP 設定がされている場合を除き、別個のブラウジングコンテキストグループに属します。そのため、開いたウィンドウに対して分離が適用され、両方のウィンドウ間の相互通信が無効になります。

注意: これにより、OAuth や支払いなど、クロスオリジンウィンドウのインタラクションを必要とする統合が機能しなくなります。この問題を軽減するため、条件を緩和して、クロスオリジン分離を Cross-Origin-Opener-Policy: same-origin-allow-popups で有効にすることを検討しています。これにより、自動的に開いたウィンドウとの通信が可能になります。クロスオリジン分離を有効にしたいが、この問題によってブロックされている場合は、オリジントライアルに登録して、新しい条件が利用可能になるまで待つことをおすすめします。この問題が安全に解決されるまで、オリジントライアルを終了する予定はありません。

ブラウジングコンテキストグループは、相互に参照できるウィンドウのセットです。たとえば、最上位のドキュメントと、<iframe> を介して埋め込まれた子ドキュメントです。ウェブサイト（https://a.example）がポップアップウィンドウ（https://b.example）を開くと、オープナーウィンドウとポップアップウィンドウは同じブラウジングコンテキストを共有するため、window.opener などの DOM API を介して互いにアクセスできます。

ブラウジングコンテキストグループ

ウィンドウを開いた側と開かれた側が別々のブラウジングコンテキストグループに属しているかどうかは、DevTools で確認できます。

2. リソースで CORP または CORS が有効になっていることを確認する

ページ内のすべてのリソースが CORP または CORS HTTP ヘッダーで読み込まれるようにします。このステップは、ステップ 4 の COEP の有効化に必要です。

リソースの性質に応じて、次の操作を行います。

リソースが同じオリジンからのみ読み込まれることが想定される場合は、Cross-Origin-Resource-Policy: same-origin ヘッダーを設定します。
リソースが同じサイトからのみ読み込まれるが、クロスオリジンであることが想定される場合は、Cross-Origin-Resource-Policy: same-site ヘッダーを設定します。
リソースが制御下のクロスオリジンから読み込まれる場合は、可能であれば Cross-Origin-Resource-Policy: cross-origin ヘッダーを設定します。
制御できないクロスオリジンリソースの場合:
- リソースが CORS で配信される場合は、読み込み HTML タグで crossorigin 属性を使用します。（たとえば <img src="***" crossorigin>）で保護しなければなりません。
- リソースのオーナーに CORS または CORP のいずれかをサポートするよう依頼します。
iframe の場合は、上記の原則に従って Cross-Origin-Resource-Policy: cross-origin（またはコンテキストに応じて same-site、same-origin）を設定します。
WebWorker で読み込まれたスクリプトは同一オリジンから提供されるため、CORP ヘッダーや CORS ヘッダーは必要ありません。
COEP: require-corp で配信されるドキュメントまたはワーカーの場合、CORS なしで読み込まれるクロスオリジンサブリソースは、埋め込みをオプトインするために Cross-Origin-Resource-Policy: cross-origin ヘッダーを設定する必要があります。たとえば、<script>、importScripts、<link>、<video>、<iframe> などに適用されます。

iframe 内に埋め込まれたドキュメントでクロスオリジン分離を有効にするには、<iframe> タグに allow="cross-origin-isolated" 権限ポリシーを適用し、このドキュメントで説明されている同じ条件を満たします。親フレームと子フレームを含むドキュメントのチェーン全体もクロスオリジン分離されている必要があります。

3. COEP Report-Only HTTP ヘッダーを使用して埋め込みリソースを評価する

COEP を完全に有効にする前に、Cross-Origin-Embedder-Policy-Report-Only ヘッダーを使用してドライランを実行し、ポリシーが実際に機能するかどうかを確認できます。埋め込みコンテンツをブロックせずにレポートを受け取ります。

最上位ドキュメント、iframe、ワーカースクリプトを含むすべてのドキュメントに、これを再帰的に適用します。Report-Only HTTP ヘッダーについては、Reporting API を使用して問題を観察するをご覧ください。

4. COEP を有効にする

すべてが機能し、すべてのリソースが正常に読み込まれることを確認したら、Cross-Origin-Embedder-Policy-Report-Only ヘッダーを同じ値の Cross-Origin-Embedder-Policy ヘッダーに切り替えます。この切り替えは、iframe やワーカースクリプトを介して埋め込まれたドキュメントを含むすべてのドキュメントに対して行います。

注意: クロスオリジン分離ではすべてのサブリソースを明示的にオプトインする必要があるため、Cross-Origin-Resource-Policy を大規模にデプロイする方法を検討しています。そこで、逆方向のアプローチとして、すべての認証情報を削除して CORP ヘッダーなしでリソースを読み込める新しい COEP の「認証情報なし」モードを考案しました。これにより、サブリソースが Cross-Origin-Resource-Policy ヘッダーを送信していることを確認する負担が軽減されることを願っています。ただし、credentialless モードは Chrome バージョン 96 以降で利用できますが、他のブラウザではまだサポートされていないため、COOP や COEP のデプロイが難しいと感じるデベロッパーもいるかもしれません。現時点でクロスオリジン分離を有効にしない場合は、オリジントライアルに登録して、より多くのブラウザで credentialless が利用可能になるまで待つことをおすすめします。

`self.crossOriginIsolated` を使用して分離が成功したかどうかを判断する

self.crossOriginIsolated プロパティは、ウェブページがクロスオリジン分離状態にあり、すべてのリソースとウィンドウが同じブラウジングコンテキストグループ内で分離されている場合、true を返します。この API を使用すると、ブラウジングコンテキストグループを正常に分離し、performance.measureUserAgentSpecificMemory() などの強力な機能にアクセスできたかどうかを判断できます。

Chrome DevTools を使用して問題をデバッグする

画像など、画面にレンダリングされるリソースの場合、リクエストがブロックされ、ページに画像がないことが示されるため、COEP の問題を検出するのは比較的簡単です。ただし、スクリプトやスタイルなど、視覚的な影響を必ずしも伴わないリソースの場合、COEP の問題に気づかない可能性があります。そのような場合は、DevTools の [Network] パネルを使用します。COEP に問題がある場合は、[ステータス] 列に (blocked:NotSameOriginAfterDefaultedToSameOriginByCoep) が表示されます。

[Network] パネルの [Status] 列に COEP の問題が表示されます。

エントリをクリックすると、詳細が表示されます。

[ネットワーク] パネルでネットワークリソースをクリックすると、[ヘッダー] タブに COEP の問題の詳細が表示されます。

[アプリケーション] パネルで、iframe とポップアップウィンドウのステータスを確認することもできます。左側の [フレーム] セクションに移動し、[上] を展開してリソース構造の内訳を確認します。

SharedArrayBuffer の可用性など、iframe のステータスを確認できます。

ポップアップウィンドウのステータス（クロスオリジン分離されているかどうかなど）を確認することもできます。

Reporting API を使用して問題をモニタリングする

Reporting API は、さまざまな問題を検出できる別のメカニズムです。COEP がリソースの読み込みをブロックしたり、COOP がポップアップウィンドウを分離したりするたびにレポートを送信するように、ユーザーのブラウザに指示するよう Reporting API を構成できます。Chrome は、COEP や COOP など、さまざまな用途で Reporting API をバージョン 69 以降でサポートしています。

注: Report-To ヘッダーを使用して Reporting API をすでに使用していますか？Chrome は Reporting API の新しいバージョンに移行しており、Report-To が Reporting-Endpoints に置き換えられています。新しいバージョンへの移行をご検討ください。詳しくは、Reporting API v1 への移行をご覧ください。

Reporting API の構成方法とレポートを受信するサーバーの設定方法については、Reporting API の使用をご覧ください。

COEP レポートの例

クロスオリジンリソースがブロックされた場合の COEP レポートのペイロードの例は次のとおりです。

[{
  "age": 25101,
  "body": {
    "blocked-url": "https://third-party-test.glitch.me/check.svg?",
    "blockedURL": "https://third-party-test.glitch.me/check.svg?",
    "destination": "image",
    "disposition": "enforce",
    "type": "corp"
  },
  "type": "coep",
  "url": "https://cross-origin-isolation.glitch.me/?coep=require-corp&coop=same-origin&",
  "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4249.0 Safari/537.36"
}]

注意: blocked-url は下位互換性のためだけに存在し、最終的には削除されます。

COOP レポートの例

ポップアップウィンドウが分離して開かれた場合の COOP レポートのペイロードの例は次のとおりです。

[{
  "age": 7,
  "body": {
    "disposition": "enforce",
    "effectivePolicy": "same-origin",
    "nextResponseURL": "https://third-party-test.glitch.me/popup?report-only&coop=same-origin&",
    "type": "navigation-from-response"
  },
  "type": "coop",
  "url": "https://cross-origin-isolation.glitch.me/coop?coop=same-origin&",
  "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4246.0 Safari/537.36"
}]

異なるブラウジングコンテキストグループが互いにアクセスしようとすると（「レポート専用」モードの場合のみ）、COOP もレポートを送信します。たとえば、postMessage() が試行された場合のレポートは次のようになります。

[{
  "age": 51785,
  "body": {
    "columnNumber": 18,
    "disposition": "reporting",
    "effectivePolicy": "same-origin",
    "lineNumber": 83,
    "property": "postMessage",
    "sourceFile": "https://cross-origin-isolation.glitch.me/popup.js",
    "type": "access-from-coop-page-to-openee"
  },
  "type": "coop",
  "url": "https://cross-origin-isolation.glitch.me/coop?report-only&coop=same-origin&",
  "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4246.0 Safari/537.36"
},
{
  "age": 51785,
  "body": {
    "disposition": "reporting",
    "effectivePolicy": "same-origin",
    "property": "postMessage",
    "type": "access-to-coop-page-from-openee"
  },
  "type": "coop",
  "url": "https://cross-origin-isolation.glitch.me/coop?report-only&coop=same-origin&",
  "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4246.0 Safari/537.36"
}]

まとめ

COOP と COEP の HTTP ヘッダーを組み合わせて使用すると、ウェブページを特別なクロスオリジン分離状態にオプトインできます。self.crossOriginIsolated を調べて、ウェブページがクロスオリジン分離状態にあるかどうかを判断できます。

この投稿は、クロスオリジン分離状態に新しい機能が追加されたり、COOP と COEP に関する DevTools の改善がさらに進んだりするたびに更新されます。

COOP と COEP を使用してウェブサイトを「クロスオリジン分離」を実現 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

COOP と COEP をデプロイしてウェブサイトをクロスオリジン分離する

COOP と COEP を統合する

1. 最上位ドキュメントに Cross-Origin-Opener-Policy: same-origin ヘッダーを設定する

2. リソースで CORP または CORS が有効になっていることを確認する

3. COEP Report-Only HTTP ヘッダーを使用して埋め込みリソースを評価する

4. COEP を有効にする

self.crossOriginIsolated を使用して分離が成功したかどうかを判断する

Chrome DevTools を使用して問題をデバッグする

Reporting API を使用して問題をモニタリングする

COEP レポートの例

COOP レポートの例

まとめ

リソース

COOP と COEP を使用してウェブサイトを「クロスオリジン分離」を実現

1. 最上位ドキュメントに `Cross-Origin-Opener-Policy: same-origin` ヘッダーを設定する

`self.crossOriginIsolated` を使用して分離が成功したかどうかを判断する