更新
2023 年 3 月 23 日: タイムラインが更新され、Chrome 117 までサポートは終了しません。
2023 年 1 月 19 日: タイムラインが更新され、Chrome 114 までサポートは終了しません。
2022 年 8 月 12 日: タイムラインが更新されました。サポートが終了するのは Chrome 109 までです。
2022 年 2 月 10 日: プライベート ネットワーク アクセス: プリフライトのご紹介で最新の記事を公開しました
2021 年 8 月 25 日: タイムラインのお知らせと非推奨トライアルの導入を更新しました。
Chrome では、プライベート ネットワーク アクセスの仕様の一環として、保護されていないウェブサイトからのプライベート ネットワーク エンドポイントへのアクセスが非推奨になります。その目的は、プライベート ネットワーク上のルーターなどのデバイスを標的としたクロスサイト リクエスト フォージェリ（CSRF）攻撃からユーザーを保護することです。これらの攻撃は数十万人のユーザーに影響を与えており、攻撃者はユーザーを悪意のあるサーバーにリダイレクトしています。
Chrome で次の変更が行われます。
- 安全でない公開ウェブサイトからのプライベート ネットワークへのリクエストをブロックする（Chrome 94 以降）。
- Chrome で終了する非推奨トライアルのご紹介
- これにより、デベロッパーは選択したオリジンの期限延長をリクエストできます。これは非推奨トライアル期間中は影響を受けません。
- 管理対象の Chrome デプロイでサポート終了を完全に回避できるようにする Chrome ポリシーを導入します。Chrome 92 で利用できます。
非推奨による影響を軽減するために時間が必要な場合は、非推奨トライアルにご登録ください。
ユーザーに対する管理者制御がある場合は、Chrome ポリシーを使用してこの機能を再度有効にすることができます。
新しい制限の影響を軽減するには、次のいずれかの方法を使用します。
- ウェブサイトを HTTPS にアップグレードし、必要に応じてターゲット サーバーをアップグレードします。
- ウェブサイトを HTTPS にアップグレードし、WebTransport を使用する。
- エンベディング関係を逆にする。
タイムライン
- 2020 年 11 月: 今後の変更についてのフィードバックをお寄せください。
- 2021 年 3 月: フィードバックの確認とアウトリーチを行った後、今後の変更が発表されます。仕様の名前が CORS-RFC1918 からプライベート ネットワーク アクセスに変更されました。
- 2021 年 4 月: Chrome 90 が Stable 版としてリリースされ、非推奨の警告が表示されるようになります。
- 2021 年 6 月: Chrome 92 のベータ版がリリースされ、安全でないコンテキストからのプライベート ネットワーク リクエストが禁止されます。デベロッパーから調整時間の延長を求めるフィードバックを受けた後、サポート終了は Chrome 93 まで延期され、サポート終了となるトライアルが伴います。
- 2021 年 7 月: デベロッパーからさらにフィードバックを受け、サポート終了とそれに付随するトライアルは Chrome 94 まで延期されます。また、非公開のウェブサイトは非推奨による影響を受けません。
- 2021 年 8 月: Chrome 94 のベータ版をリリースします。ウェブ デベロッパーは非推奨トライアルへのお申し込みを開始できます。
- 2021 年 9 月: Chrome 94 を Stable でリリースします。ウェブ デベロッパーは、非推奨トライアルに登録し、トライアル トークンを本番環境にデプロイしておく必要があります。
- 2022 年 12 月: オリジン トライアル アンケートを送信し、フィードバックを受信。非推奨トライアルは Chrome 113 まで延長されます。
- 2023 年 3 月: 非推奨トライアルを Chrome 116 まで延長し、Chrome 117 で終了する予定です。現在、権限ベースの代替メカニズムが Chrome 114 での初期リリースに向けて開発中です。
- 2023 年 5 月（暫定）: Chrome 114 で権限ベースのメカニズムがリリースされます。 ウェブサイトはこれを使用して、非推奨トライアルを終了できます。
- 2023 年 9 月: Chrome 117 が Stable 版としてリリースされ、非推奨トライアルが終了します。 Chrome では、保護されていない公開コンテキストからのすべてのプライベート ネットワーク リクエストがブロックされます。
プライベート ネットワーク アクセスとは
プライベート ネットワーク アクセス（旧称 CORS-RFC1918）は、プライベート ネットワーク上のサーバーにリクエストを送信するウェブサイトの機能を制限します。安全なコンテキストからのリクエストのみを許可します。また、この仕様ではクロスオリジン リソース シェアリング（CORS）プロトコルが拡張されており、ウェブサイトが任意のリクエストを送信する前に、プライベート ネットワーク上のサーバーに権限を明示的にリクエストする必要があります。
プライベート ネットワーク リクエストは、ターゲット サーバーの IP アドレスが、リクエスト開始元をフェッチした IP アドレスよりもプライベートなリクエストです。たとえば、公開ウェブサイト（https://example.com）から非公開ウェブサイト（http://router.local）へのリクエストや、非公開ウェブサイトから localhost へのリクエストです。
詳しくは、フィードバックを求める: プライベート ネットワーク用の CORS（RFC1918）をご覧ください。
非推奨トライアルとは
非推奨トライアル（旧称リバース オリジン トライアル）は、ウェブ機能の非推奨を簡易化するために使用されるオリジン トライアルの一種です。サポート終了トライアルを通じて、Chrome は特定のウェブ機能を非推奨にし、ウェブサイトがそれらの機能に対する新たな依存関係を形成するのを防止します。同時に、現在依存しているウェブサイトがそれらの機能から移行するための時間を確保します。
非推奨トライアル期間中、非推奨の機能は、デフォルトではすべてのウェブサイトで使用できません。影響を受ける機能を引き続き使用する必要があるデベロッパーは、非推奨トライアルに登録し、指定したウェブオリジンのトークンを取得してから、HTTP ヘッダーまたはメタタグでそれらのトークンを提供するようにウェブサイトを変更する必要があります（この場合を除きます）。発行元に一致する有効なトークンをウェブサイトが配信している場合、Chrome では期間限定でサポートが終了した機能の使用が許可されます。
手順については、Chrome のオリジン トライアルのスタートガイドとオリジン トライアルに関するウェブ デベロッパー向けガイドをご覧ください。
Chrome の変更点
Chrome 94
Chrome 94 以降では、セキュアでない一般公開のコンテキスト（広範には、HTTPS 経由またはプライベート IP アドレスから配信されていないウェブサイト）からプライベート ネットワークへのリクエストが禁止されます。これは以前 Chrome 92 で予定されていた機能であるため、サポート終了のメッセージで以前のマイルストーンが引き続き言及される場合があります。
このサポート終了には、サポート終了トライアルが伴います。ウェブサイトでサポート終了の機能を使用しているウェブ デベロッパーは、トークンを登録して Chrome 116 までその機能を引き続き使用できます。ウェブサイトでトライアルを登録して有効にする手順については、下記をご覧ください。
ペアの Chrome ポリシーを使用すると、サポート終了を完全に無効にすることも、特定のオリジンで無期限に無効にすることもできます。これにより、管理対象の Chrome インストール（企業設定など）で障害が発生しないようにすることができます。
Chrome 117
非推奨トライアルが終了する。サポートが終了した機能からすべてのウェブサイトを移行するか、引き続きこの機能を有効にするようにユーザーのユーザー ポリシーを構成する必要があります。
デベロッパーに推奨される対応
影響を受けるウェブサイトに対する最初のステップとして、適切な修正（非推奨トライアルに登録するか、ポリシーを使用するなど）が実装されるまで、ある程度の時間が必要になります。推奨される対応策は、影響を受ける各ウェブサイトの状況によって異なります。
非推奨トライアルに登録する
- セキュアでないコンテキストからのプライベート ネットワーク アクセスのオリジン トライアルで [登録] をクリックして、参加するオリジンのトライアル トークンを取得します。
- オリジン固有の
Origin-Trial: $tokenをレスポンス ヘッダーに追加します。このレスポンス ヘッダーは、生成されるドキュメントで非推奨の機能が使用されている場合にのみ、メインリソースとナビゲーションのレスポンスで設定する必要があります。このヘッダーをサブリソース レスポンスにアタッチしても（無害ですが）、無意味です。
ドキュメントにリクエストを許可する前に、このトライアルを有効または無効にする必要があるため、<meta> タグを使用してトライアルを有効にすることはできません。このようなタグは、サブリソース リクエストが発行された後にのみ、レスポンス本文から解析されます。これは、サードパーティが提供する github.io 静的ウェブサイトなど、レスポンス ヘッダーを制御できないウェブサイトにとって課題となります。
詳しくは、オリジン トライアルに関するウェブ デベロッパー ガイドをご覧ください。
ポリシーを有効化
ユーザーに対する管理権限がある場合は、次のいずれかのポリシーを使用して非推奨の機能を再度有効にすることができます。
ユーザー向けのポリシーの管理について詳しくは、こちらのヘルプセンター記事をご覧ください。
localhost へのアクセス
ウェブサイトで localhost にリクエストを発行する必要がある場合は、ウェブサイトを HTTPS にアップグレードするだけです。
http://localhost（または http://127.*.*.*、http://[::1]）を対象とするリクエストは、安全なコンテキストから発行された場合でも、混合コンテンツによってブロックされません。
WebKit エンジンとそれに基づくブラウザ（特に Safari）は、この W3C の混合コンテンツの仕様から逸脱しており、こうしたリクエストを混合コンテンツとして禁止しています。また、プライベート ネットワーク アクセスは実装されていないため、ウェブサイトは、そのようなブラウザを使用するクライアントをウェブサイトの平文の HTTP バージョンにリダイレクトすることを必要とする場合があります。この場合、そのようなブラウザは localhost にリクエストを送信できます。
プライベート IP アドレスへのアクセス
ウェブサイトからターゲット サーバーにプライベート IP アドレスでリクエストを発行する必要がある場合は、イニシエータ ウェブサイトを HTTPS にアップグレードするだけでは機能しません。混合コンテンツにより、安全なコンテキストは書式なしテキストの HTTP 経由でリクエストを発行できなくなるため、新しく保護されたウェブサイトでもリクエストを送信できません。この問題を解決する方法はいくつかあります。
- 両端を HTTPS にアップグレードします。
- WebTransport を使用してターゲット サーバーに安全に接続します。
- エンベディング関係を逆にします。
両端を HTTPS にアップグレードする
このソリューションでは、イントラネットのコンテキストの場合や、ユーザーが制御している DHCP サーバーからネームサーバーのアドレスを取得する場合など、ユーザーの DNS 解決を制御する必要があります。また、パブリック ドメイン名を所有している必要があります。
HTTPS 経由で限定公開ウェブサイトを提供する場合の主な問題は、公開鍵基盤認証局（PKI CA）がパブリック ドメイン名のウェブサイトにのみ TLS 証明書を提供することです。この問題を回避するには:
- パブリック ドメイン名（
intranet.exampleなど）を登録し、そのドメイン名を指す DNS レコードを、選択したパブリック サーバーに公開します。 intranet.exampleの TLS 証明書を取得します。- プライベート ネットワーク内で、
intranet.exampleをターゲット サーバーのプライベート IP アドレスに解決するように DNS を構成します。 intranet.exampleの TLS 証明書を使用するようにプライベート サーバーを構成します。これにより、ユーザーがhttps://intranet.exampleのプライベート サーバーにアクセスできるようになります。
その後、リクエストを開始するウェブサイトを HTTPS にアップグレードし、以前と同様にリクエストを行うことができます。
このソリューションは将来性があり、ネットワークへの信頼を低下させ、プライベート ネットワーク内でエンドツーエンドの暗号化の使用を拡大します。
WebTransport
このソリューションでは、ユーザーの DNS 解決を制御する必要はありません。ターゲット サーバーは、最小限の WebTransport サーバー（HTTP/3 サーバーを変更したもの）を実行する必要があります。
WebTransport とその証明書ピン留めメカニズムを使用すると、信頼できる CA によって署名された有効な TLS 証明書が存在しないことを回避できます。これにより、たとえば自己署名証明書を持つプライベート デバイスへの安全な接続を確立できます。WebTransport 接続では、双方向のデータ転送は可能ですが、フェッチ リクエストはできません。ウェブ アプリケーションの観点から、このアプローチを Service Worker と組み合わせると、接続を介して HTTP リクエストを透過的にプロキシできます。サーバー側では、対応する変換レイヤが WebTransport メッセージを HTTP リクエストに変換できます。
これにはかなりの作業が必要になりますが、WebRTC 上に構築するよりもはるかに簡単でしょう。また、必要な投資のある程度は再利用可能なライブラリとして実装されることも期待しています。また、プラットフォームが時間の経過とともに HTTPS の使用をより強く推奨する方向に移行していくにつれ、セキュアでないコンテキストではアクセスできなくなるウェブ プラットフォーム機能が増加する可能性があるという事実を考慮することも、特に価値があると Google は考えています。プライベート ネットワーク アクセスに関係なく、これは賢明な投資となる可能性があります。
Chrome 96 では、HTTP/3 経由の WebTransport がリリースされる見込みです（オリジン トライアルが開始されています）。この実装では、鍵の共有やその他の基準に即さないセキュリティ対策から、次のような対策が講じられる予定です。
- 固定された証明書の最大有効期限を短くします。
- 不正使用の被害を受けた特定のキーを取り消すブラウザ固有のメカニズム。
セキュア コンテキストの制限は、WebTransport が完全にロールアウトされてから少なくとも 2 つのマイルストーンまでは提供されません。非推奨トライアルは、必要に応じて延長されます。
逆埋め込み
このソリューションでは、ネットワークに対する管理制御が不要であり、ターゲット サーバーが HTTPS を実行するのに十分なパワーを持っていない場合に使用できます。
公開ウェブアプリからプライベート サブリソースを取得する代わりに、アプリのスケルトンをプライベート サーバーから提供できます。プライベート サーバーは、すべてのサブリソース（スクリプトや画像など）を CDN などの公開サーバーから取得します。作成されたウェブアプリは、同一オリジンとみなされるため、プライベート サーバーにリクエストを送信できます。プライベート IP を持つ（ただし localhost ではない）他のサーバーにリクエストを行うこともできますが、これは長期的に変更される可能性があります。
プライベート サーバーでスケルトンだけをホストすると、一般公開のウェブアプリを更新する場合と同様に、新しいリソースを公開サーバーに push してウェブアプリを更新できます。一方、作成されるウェブアプリは安全なコンテキストではないため、ウェブのより強力な機能の一部にアクセスできません。
今後の計画
プライベート ネットワーク リクエストを安全なコンテキストに制限することは、プライベート ネットワーク アクセスを開始するための最初のステップにすぎません。Chrome では今後数か月以内に、仕様の残りの部分の実装を進めています。今後の最新情報をお待ちください。
非公開ウェブサイトからのローカルホスト アクセスを制限する
Chrome 94 での変更は、プライベート IP アドレスまたは localhost にアクセスする公開ウェブサイトにのみ影響します。プライベート ネットワーク アクセスの仕様では、プライベート ウェブサイトから localhost へのリクエストも問題として分類されています。これらも最終的にはサポート終了となります。ただし、ドメイン名のない非公開ウェブサイトが多く、非推奨トライアル トークンの使用が複雑になります。
CORS プリフライト リクエスト
プライベート ネットワーク アクセスの 2 つ目の部分は、CORS プリフライト リクエストを使用して、安全なコンテキストから開始されるプライベート ネットワーク リクエストを制御することです。これは、リクエストが安全なコンテキストから開始された場合でも、ターゲット サーバーはイニシエータに明示的な権限を付与するよう求めるというものです。リクエストは、権限付与が成功した場合にのみ送信されます。
簡潔に言うと、CORS プリフライト リクエストは、後続のリクエストの性質を示す Access-Control-Request-* ヘッダーを含む HTTP OPTIONS リクエストです。これにより、サーバーは Access-Control-Allow-* ヘッダーで 200 OK に応答することで、きめ細かいアクセスを許可するかどうかを決定できます。
詳細については、仕様をご覧ください。
ナビゲーションの取得を制限する
Chrome では、プライベート ネットワークへのサブリソース リクエストを非推奨とし、最終的にブロックしています。これは、CSRF 攻撃でも使用されるプライベート ネットワークへのナビゲーションには影響しません。
プライベート ネットワーク アクセスの仕様では、この 2 種類のフェッチは区別されず、最終的に同じ制限が適用されます。
Markus Spiske 氏によるカバー写真（Unsplash）