ウェブサイトで document.domain
の設定に依存している場合は、対応が必要です。
更新
- 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
は、送信元のホスト名を取得または設定するように設計されています。
Chrome では、ウェブサイトで document.domain
を設定できなくなります。クロスオリジン通信には、postMessage()
や Channel Messaging API などの別の方法を使用する必要があります。この変更は、早ければ Chrome 112 でリリースされる予定ですが、リリースの意向に対する回答に依存します。
適切に動作させるために document.domain
を使用した同一オリジン ポリシーの緩和を利用しているウェブサイトでは、その動作が必要なすべてのドキュメントに Origin-Agent-Cluster: ?0
ヘッダーを付けて送信する必要があります(document.domain
は、1 つのドキュメントのみが設定した場合は効果がありません)。
document.domain
を不変にする理由
多くのウェブサイトでは、同一サイトのクロスオリジンページ間の通信を許可するために document.domain
を設定しています。
使用方法は次のとおりです。
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] パネルに警告が表示されます。右上に黄色の旗が表示されています。
レポート エンドポイントが設定されている場合は、非推奨レポートも送信されます。既存のレポート収集サービスを使用するか、独自の社内ソリューションを構築して Reporting API を使用する方法について学びます。
サイトで LightHouse 非推奨 API の監査を実行すると、Chrome からの削除が予定されているすべての API を確認できます。
クロスオリジン通信の代替手段
現在のところ、ウェブサイトの document.domain
を置き換える方法は 3 つあります。
postMessage()
または Channel Messaging API を使用する
ほとんどのユースケースでは、クロスオリジンの postMessage()
または Channel Messaging API で document.domain
を置き換えられます。
下記の例で、
https://parent.example.com
は iframe 内でhttps://video.example.com
をリクエストし、postMessage()
を介してメッセージを送信して DOM を操作します。https://video.example.com
は、メッセージを受信するとすぐに DOM を操作し、成功を親に通知します。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 より)