同一オリジン ポリシーを緩和するために document.domain を変更できなくなります

ウェブサイトで document.domain の設定に依存している場合は、対応が必要です。

Eiji Kitamura

更新

• 2023 年 5 月 30 日: document.domain セッターが Chrome 115 で非推奨になることをお知らせしました。
• 2023 年 4 月 7 日: Chrome 112 でこの変更をリリースする前に、問題を特定しました。デフォルトで削除される document.domain セッターは現在停止されており、新しいリリース マイルストーンは未定です。このブログ投稿をもう一度確認するか、blink-dev とこちらのスレッドを購読してください。
• 2023 年 1 月 20 日: タイムラインの更新 - Chrome 112 以降、document.domain セッターがデフォルトで削除されます。また、document.domain の動作を制御するエンタープライズ ポリシーに関する記述も追加されました。
• 2022 年 7 月 25 日: タイムラインの更新 - Chrome 109 以降、document.domain セッターがデフォルトで削除されます。
• 2022 年 2 月 4 日: 新しいタイムラインを更新しました。Chrome 100 以降は [問題] パネルに警告が表示され、Chrome 106 以降はデフォルトで document.domain セッターが削除されます。

警告: ウェブサイトが document.domain による同一オリジン ポリシーの緩和に依存している場合は、対応が必要です。今回の変更理由について詳細を確認するか、クロスオリジン通信の代替コードに進んでください。

document.domain は、送信元のホスト名を取得または設定するように設計されています。

Chrome では、ウェブサイトで document.domain を設定できなくなります。クロスオリジン通信には、postMessage() や Channel Messaging API などの別の方法を使用する必要があります。この変更は、早ければ Chrome 112 でリリースされる予定ですが、リリースの意向に対する回答に依存します。

適切に動作させるために document.domain を使用した同一オリジン ポリシーの緩和を利用しているウェブサイトでは、その動作が必要なすべてのドキュメントに Origin-Agent-Cluster: ?0 ヘッダーを付けて送信する必要があります（document.domain は、1 つのドキュメントのみが設定した場合は効果がありません）。

document.domain を不変にする理由

多くのウェブサイトでは、同一サイトのクロスオリジンページ間の通信を許可するために document.domain を設定しています。

重要な用語: 同じサイトでもクロスオリジンのサイトは、eTLD+1 は同じでもサブドメインが異なります。

使用方法は次のとおりです。

https://parent.example.com のページに https://video.example.com の iframe ページが埋め込まれているとします。これらのページは、同じ eTLD+1（example.com）で、サブドメインが異なります。両方のページの document.domain が 'example.com' に設定されている場合、ブラウザは 2 つのオリジンを同じオリジンとして扱います。

https://parent.example.com の document.domain を設定します。

// Confirm the current origin of "parent.example.com"
console.log(document.domain);

// Set the document.domain
document.domain = 'example.com';
console.log(document.domain);

https://video.example.com の document.domain を設定します。

// Confirm the current origin of "video.example.com"
console.log(document.domain);

// Set the document.domain
document.domain = 'example.com';
console.log(document.domain);

https://video.example.com に対して https://parent.example.com でクロスオリジン DOM 操作を作成できるようになりました。

ウェブサイトは、同じサイトのドキュメントがより簡単に通信できるように document.domain を設定します。この変更により同一オリジン ポリシーが緩和されるため、親ページは iframe のドキュメントにアクセスして DOM ツリーを走査できるようになります。その逆も同様です。

これは便利な手法ですが、セキュリティ上のリスクが発生します。

document.domain のセキュリティに関する懸念

document.domain にはセキュリティ上の懸念があるため、使用を避けるようにユーザーに警告する仕様が変更されました。他のブラウザ ベンダーとの現在の議論も同じ方向に進んでいます。

たとえば、2 つのページで document.domain が設定されている場合、それらが同じオリジンであるように見せかけることができます。これらのページで異なるサブドメインの共有ホスティング サービスが使用されている場合は特に重要です。document.domain を設定すると、同じサービスでホストされている他のすべてのサイトにアクセスできるようになります。これにより、攻撃者がサイトに簡単にアクセスできるようになります。これは、document.domain がドメインのポート番号部分を無視するためです。

document.domain の設定によるセキュリティへの影響については、MDN の「Document.domain」のページをご覧ください。

Chrome は、Chrome 112 で document.domain を不変にすることを計画しています。

サイトが影響を受けているかどうかを確認するにはどうすればよいですか？

ウェブサイトがこの変更の影響を受ける場合は、Chrome の DevTools の [Issues] パネルに警告が表示されます。右上に黄色の旗が表示されています。

document.domain が変更されると、[問題] パネルに警告が表示されます。

レポート エンドポイントが設定されている場合は、非推奨レポートも送信されます。既存のレポート収集サービスを使用するか、独自の社内ソリューションを構築して Reporting API を使用する方法について学びます。

サイトで LightHouse 非推奨 API の監査を実行すると、Chrome からの削除が予定されているすべての API を確認できます。

クロスオリジン通信の代替手段

現在のところ、ウェブサイトの document.domain を置き換える方法は 3 つあります。

postMessage() または Channel Messaging API を使用する

ほとんどのユースケースでは、クロスオリジンの postMessage() または Channel Messaging API で document.domain を置き換えられます。

下記の例で、

1. https://parent.example.com は iframe 内で https://video.example.com をリクエストし、postMessage() を介してメッセージを送信して DOM を操作します。
2. https://video.example.com は、メッセージを受信するとすぐに DOM を操作し、成功を親に通知します。
3. https://parent.example.com は成功を通知します。

https://parent.example.com:

// Send a message to https://video.example.com
iframe.postMessage('Request DOM manipulation', 'https://video.example.com');

// Receive messages
iframe.addEventListener('message', (event) => {
  // Reject all messages except ones from https://video.example.com
  if (event.origin !== 'https://video.example.com') return;

  // Filter success messages
  if (event.data === 'succeeded') {
    // DOM manipulation is succeeded
  }
});

https://video.example.com:

// Receive messages
window.addEventListener('message', (event) => {
  // Reject all messages except ones from https://parent.example.com
  if (event.origin !== 'https://parent.example.com') return;

  // Do a DOM manipulation on https://video.example.com.

  // Send a success message to https://parent.example.com
  event.source.postMessage('succeeded', event.origin);
});

ぜひお試しください。postMessage() または Channel Messaging API では対応できない特定の要件がある場合は、Twitter の @ChromiumDev でお問い合わせいただくか、Stack Overflow で document.domain タグを使用してお問い合わせください。

最後の手段として、Origin-Agent-Cluster: ?0 ヘッダーを送信する

document.domain の設定を継続する正当な理由がある場合は、ターゲット ドキュメントとともに Origin-Agent-Cluster: ?0 レスポンス ヘッダーを送信できます。

Origin-Agent-Cluster: ?0

Origin-Agent-Cluster ヘッダーは、ドキュメントをオリジンキー エージェント クラスタで処理するかどうかをブラウザに指示します。Origin-Agent-Cluster の詳細については、Origin-Agent-Cluster ヘッダーを使用してパフォーマンス分離をリクエストするをご覧ください。

このヘッダーを送信すると、ドキュメントはデフォルトで変更不可になっても document.domain を設定し続けることができます。

企業向けポリシーの OriginAgentClusterDefaultEnabled を構成する

必要に応じて、管理者は OriginAgentClusterDefaultEnabled ポリシーを false に構成して、組織全体の Chrome インスタンスで document.domain をデフォルトで設定できるようにします。詳しくは、Chrome Enterprise のポリシーリストと管理 | ドキュメントをご覧ください。

ブラウザの互換性

• オリジンの仕様には、この機能を削除する必要があることが明記されています。
• Mozilla は、デフォルトで document.domain を無効にすることをプロトタイプ化に値すると考えています。
• WebKit は、document.domain セッターのデプリケーションに比較的前向きであるという回答をしています。

リソース

• Document.domain - ウェブ API | MDN
• 送信元の分離と非推奨化 document.domain
• document.domain の非推奨。· 問題 #564 · w3ctag/design-reviews

謝辞

写真撮影: Braydon Anderson（Unsplash より）