| layout | title | authors | date | updated | subhead | description | tags | ||
|---|---|---|---|---|---|---|---|---|---|
post |
クロスオリジンアイソレーションを有効にするためのガイド |
|
2021-02-09 |
2021-08-05 |
クロスオリジンアイソレーションを使用すると、ウェブページで SharedArrayBuffer のような強力な機能を使用できるようになります。この記事では、ウェブサイトでクロスオリジンアイソレーションを有効にする方法について説明します。 |
クロスオリジンアイソレーションを使用すると、ウェブページで SharedArrayBuffer のような強力な機能を使用できるようになります。この記事では、ウェブサイトでクロスオリジンアイソレーションを有効にする方法について説明します。 |
|
このガイドでは、Cross-Origin Isolation (クロスオリジンアイソレーション) を有効にする方法を説明します。クロスオリジンアイソレーションは、SharedArrayBuffer や performance.measureUserAgentSpecificMemory()、高精度の高解像度タイマーを使用する場合に必要となります。
クロスオリジンアイソレーションを有効にする場合は、広告の配置など、ウェブサイト上の他のクロスオリジンリソースに与える影響を評価してください。
{% Details %} {% DetailsSummary %} SharedArrayBuffer がウェブサイト上のどこで使用されているかを判断します。
Chrome 92 以降、SharedArrayBuffer を使用する機能は、クロスオリジンアイソレーションがないと動作しなくなります。SharedArrayBuffer が非推奨となったことを告げるメッセージを見てこのページにたどり着いたのであれば、お使いのウェブサイトまたはそのウェブサイトに埋め込まれているリソースの 1 つが SharedArrayBuffer を使用している可能性があります。これが非推奨となったためにウェブサイトサイトで問題が発生するということがないように、まずは使用されている場所を特定します。
{% endDetailsSummary %}
{% Aside 'objective' %}
- クロスオリジンアイソレーションを有効にして、
SharedArrayBufferを引き続き使用できるようにします。 SharedArrayBufferを使用するサードパーティのコードに依存している場合は、サードパーティのプロバイダーに何らかの措置を取るよう通知してください。 {% endAside %}
SharedArrayBuffer がサイトのどこで使用されているかわからない場合は、次の 2 つの方法で確認できます。
- ChromeDevTools を使う
- (高度) 非推奨のレポート機能を使う
SharedArrayBufferを使用している場所がすでにわかっている場合は、クロスオリジンアイソレーションの影響を分析するにスキップしてください。
Chrome DevTools を使用すると、開発者はウェブサイトを検査できます。
- SharedArrayBuffer を使用していると思われるページで Chrome DevTools を開きます。
- コンソールパネルを選択します。
- ページに
SharedArrayBufferが使用されている場合は、次のメッセージが表示されます。[Deprecation] SharedArrayBuffer will require cross-origin isolation as of M92, around May 2021. See https://developer.chrome.com/blog/enabling-shared-array-buffer/ for more details. common-bundle.js:535 - メッセージの最後に記載されているファイル名と行番号 (たとえば、
common-bundle.js:535) は、SharedArrayBufferがどこから取得されているのかを示しています。サードパーティのライブラリの場合は、開発者に連絡して問題を修正してください。ウェブサイトの一部として実装されている場合は、以下のガイドに従って、クロスオリジンアイソレーションを有効にしてください。
一部のブラウザには、非推奨になる API を指定されたエンドポイントに報告する機能があります。
- 非推奨レポートサーバーをセットアップし、報告する URL を取得します。これは、公共のサービスを使用するか、独自に構築して行います。
- URL を使って、
SharedArrayBufferを提供している可能性のあるページに次の HTTP ヘッダーを設定します。Report-To: {"group":"default","max_age":86400,"endpoints":[{"url":"THE_DEPRECATION_ENDPOINT_URL"}]} - ヘッダーの伝播が開始されると、登録したエンドポイントが非推奨レポートの収集を開始します。
こちらの実装例を参照してください： https://cross-origin-isolation.glitch.me。
{% endDetails %}
クロスオリジンアイソレーションを有効にすることがサイトに与える影響を何も破損せずに評価できたら非常に便利だと思いませんか？Cross-Origin-Opener-Policy-Report-Only および Cross-Origin-Embedder-Policy-Report-Only ヘッダーを使用すると、それを実際に行うことができます。
- トップレベルドキュメントで
Cross-Origin-Opener-Policy-Report-Only: same-originを設定します。名前から分かるように、このヘッダーは、COOP: same-originがサイトに与えると思われる影響に関するレポートのみを送信します。ポップアップウィンドウとの通信が無効化されることはありません。 - レポートを設定し、レポートを受信して保存するようにウェブサーバーを設定します。
- トップレベルのドキュメントで
Cross-Origin-Embedder-Policy-Report-Only: require-corpを設定します。ここでも、COEP: require-corpを有効化することのインパクトをサイトに影響を与えずに確認することができます。このヘッダーは、前のステップでセットアップした同じレポートサーバーにレポートを送信するように設定できます。
{% Aside %} Chrome DevTools のネットワークパネルのドメイン列を有効化することにより、影響を受けると思われるリソースの全体像を確認することもできます。{% endAside %}
{% Aside 'caution' %}
クロスオリジンアイソレーションを有効にすると、明示的にオプトインしていないクロスオリジンリソースの読み込みがブロックされ、トップレベルのドキュメントがポップアップウィンドウと通信できなくなります。
クロスオリジンアイソレーションではすべてのサブリソースを明示的にオプトインする必要があるため、Cross-Origin-Resource-Policy を大規模にデプロイする方法を模索してきました。そして、真逆の手段、つまり、すべてのクレデンシャルを削除することで、CORP ヘッダーなしでリソースをロードできる新しい COEP の「クレデンシャルなし」モードを採用するというアイデアを思いつきました。どのように機能させるかについて、詳細は現在考えている最中ですが、サブリソースによって Cross-Origin-Resource-Policy ヘッダーが送信されることを確認する手間が軽減されることを願っています。
また、Cross-Origin-Opener-Policy: same-origin ヘッダーにより、OAuth や支払いなどのクロスオリジンウィンドウのインタラクションを必要とする統合が断たれてしまうことが分かっています。この問題を緩和するために、条件を緩和して、Cross-Origin-Opener-Policy: same-origin-allow-popups に対するクロスオリジンアイソレーションを有効にすることを検討しています。このようにして、自らを開くウィンドウとの通信が可能になります。
クロスオリジンアイソレーションを有効にしたいが、これらの課題に先に進めない場合は、オリジントライアルに登録し、新しいモードが利用可能になるまでお待ちいただくことをお勧めします。新しいモードが利用可能になるまで、オリジントライアルを終了する予定はありません。
{% endAside %}
以下は、どのリソースがクロスオリジンアイソレーションの影響を受けるのかを判断した後に、そうしたクロスオリジンリソースを実際にオプトインする際のガイドラインです。
- 画像、スクリプト、スタイルシート、iframe などのクロスオリジンリソースに対して、
Cross-Origin-Resource-Policy: cross-originヘッダーを設定します。同じサイトのリソースには、Cross-Origin-Resource-Policy: same-siteヘッダーを設定します。 - リソースが CORS で提供される場合は、トップレベルドキュメントの HTML タグに
crossorigin属性を設定します (<img src="example.jpg" crossorigin>のようにする)。 - iframe にロードされたクロスオリジンリソースに iframe の別のレイヤーが含まれる場合は、このセクションで説明している手順を再帰的に適用してから続行してください。
- すべてのクロスオリジンリソースがオプトインされていることを確認したら、iframe にロードされたクロスオリジンリソースに対して
Cross-Origin-Embedder-Policy: require-corpヘッダーを設定します。 postMessage()経由の通信を必要とするクロスオリジンポップアップウィンドウがないことを確認してください。クロスオリジンアイソレーションが有効になっている状態でそれらを継続的に機能させることはできません。通信をクロスオリジンアイソレーションが有効な別のドキュメントに移動したり、別の通信方法 (HTTP リクエストなど) を使用したりできます。
以下は、クロスオリジンアイソレーションによる影響を軽減した後にクロスオリジンアイソレーションを有効にするためガイドラインです。
- トップレベルのドキュメントに
Cross-Origin-Opener-Policy: same-originヘッダーを設定します。Cross-Origin-Opener-Policy-Report-Only: same-originを設定している場合は、それを置き換えます。これにより、トップレベルのドキュメントとそのポップアップウィンドウとの通信がブロックされます。 - トップレベルのドキュメントに
Cross-Origin-Embedder-Policy: require-corpヘッダーを設定します。Cross-Origin-Embedder-Policy-Report-Only: require-corpを設定している場合は、それを置き換えます。これにより、オプトインされていないクロスオリジンリソースのロードがブロックされます。 self.crossOriginIsolatedがtrueを返すことを確認して、ページのクロスオリジンアイソレーションが有効であることを確認します。
{% Aside 'gotchas' %}
シンプルなサーバーはヘッダーの送信をサポートしていないため、ローカルサーバーでクロスオリジンアイソレーションを有効にするのは面倒な場合があります。コマンドラインフラグ --enable-features=SharedArrayBuffer を使って Chrome を起動すれば、クロスオリジンアイソレーションを有効にしなくても SharedArrayBuffer を有効にできます。それぞれのプラットフォームでコマンドラインフラグを使って Chrome を起動する方法を見る。
{% endAside %}