更新
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 バージョンにリダイレクトすることを検討できます。このようなブラウザでも、ローカルホストへのリクエストは引き続き許可されます。
プライベート IP アドレスへのアクセス
ウェブサイトがプライベート IP アドレスのターゲット サーバーにリクエストを発行する必要がある場合、イニシエータのウェブサイトを HTTPS にアップグレードするだけでは機能しません。混合コンテンツにより、セキュアなコンテキストがプレーンテキスト HTTP 経由でリクエストを送信できなくなるため、新しく保護されたウェブサイトは引き続きリクエストを送信できません。この問題を解決するには、いくつかの方法があります。
- 両端を HTTPS にアップグレードします。
- WebTransport を使用してターゲット サーバーに安全に接続します。
- エンベディング関係を逆にします。
両端を HTTPS にアップグレードする
このソリューションでは、ユーザーの DNS 解決を制御する必要があります。たとえば、イントラネット コンテキストの場合や、ユーザーが管理対象の DHCP サーバーから名前サーバーのアドレスを取得する場合などです。また、パブリック ドメイン名を所有している必要があります。
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 サーバー）を実行する必要があります。
信頼できる CA によって署名された有効な TLS 証明書がない場合は、WebTransport とその証明書ピン留めメカニズムを使用して回避できます。これにより、自己署名証明書が存在する可能性のあるプライベート デバイスへの安全な接続を確立できます。WebTransport 接続では、双方向のデータ転送が可能です。ただし、フェッチ リクエストは許可されません。このアプローチをサービス ワーカーと組み合わせることで、ウェブ アプリケーションの観点から、接続経由で HTTP リクエストを透過的にプロキシできます。サーバーサイドでは、対応する変換レイヤが WebTransport メッセージを HTTP リクエストに変換できます。
これはかなりの作業量になることは認識しておりますが、WebRTC 上に構築するよりもはるかに簡単なはずです。また、必要な投資の一部が再利用可能なライブラリとして実装されることも期待しています。また、プラットフォームが HTTPS の使用をより強く推奨する方向に進むにつれて、安全でないコンテキストはウェブ プラットフォームの機能にアクセスできなくなる可能性が高いという点も考慮する必要があります。プライベート ネットワーク アクセスに関係なく、これは賢明な投資である可能性が高いでしょう。
HTTP/3 を介した WebTransport は Chrome 96 でリリースされる予定です（オリジン トライアルが開始されています）。鍵の共有やその他の標準以下のセキュリティ対策から保護するための緩和策が用意されています。
- 固定された証明書の有効期限の最長時間を短くする。
- 不正使用の対象となった特定のキーを取り消すためのブラウザ固有のメカニズム。
安全なコンテキストの制限は、WebTransport が完全にロールアウトされてから少なくとも 2 つのマイルストーンが経過するまでリリースされません。必要に応じて、非推奨トライアルは延長されます。
リバース エンベディング
このソリューションでは、ネットワークを管理する必要はありません。また、ターゲット サーバーが HTTPS を実行するのに十分な性能がない場合にも使用できます。
パブリック ウェブアプリから非公開のサブリソースを取得する代わりに、アプリのスケルトンをプライベート サーバーから提供し、そのプライベート サーバーが CDN などのパブリック サーバーからすべてのサブリソース（スクリプトや画像など）を取得できます。作成されたウェブアプリは、同じオリジンと見なされるため、プライベート サーバーにリクエストを送信できます。プライベート IP を持つ他のサーバーにリクエストを送信することもできます（localhost は除く）。ただし、これは長期的には変更される可能性があります。
プライベート サーバーにスケルトンのみをホストすることで、一般公開ウェブアプリを更新する場合と同様に、新しいリソースを一般公開サーバーに push してウェブアプリを更新できます。一方、生成されたウェブアプリは安全なコンテキストではないため、ウェブの高度な機能の一部にアクセスできません。
今後のプラン
プライベート ネットワーク リクエストをセキュアなコンテキストに制限することは、プライベート ネットワーク アクセスを開始する最初のステップにすぎません。Chrome では、今後数か月以内に残りの仕様を実装する予定です。最新情報を随時ご確認ください。
限定公開ウェブサイトからの localhost アクセスを制限する
Chrome 94 の変更は、プライベート IP アドレスまたは localhost にアクセスする公開ウェブサイトにのみ影響します。プライベート ネットワーク アクセスの仕様では、限定公開ウェブサイトからローカルホストへのリクエストも問題のあるリクエストとして分類されています。Chrome では最終的にこれらもサポートを終了する予定です。ただし、多くの非公開ウェブサイトにはドメイン名がないため、非推奨トライアル トークンの使用が複雑になるという、若干異なる課題があります。
CORS プリフライト リクエスト
プライベート ネットワーク アクセスの 2 つ目の部分は、CORS プリフライト リクエストを使用して、セキュアなコンテキストから開始されたプライベート ネットワーク リクエストをゲートすることです。リクエストが安全なコンテキストから開始された場合でも、ターゲット サーバーは開始元に明示的な権限を付与するよう求められます。リクエストは、付与が成功した場合にのみ送信されます。
要するに、CORS プリフライト リクエストは、後続のリクエストの性質を示す Access-Control-Request-* ヘッダーを含む HTTP OPTIONS リクエストです。サーバーは、Access-Control-Allow-* ヘッダーで 200 OK にレスポンスを返すことで、きめ細かいアクセス権を付与するかどうかを決定できます。
詳しくは、仕様をご覧ください。
ナビゲーションの取得を制限する
Chrome では、プライベート ネットワークへのサブリソース リクエストのサポートが終了し、最終的にはブロックされます。これは、CSRF 攻撃にも使用できるプライベート ネットワークへのナビゲーションには影響しません。
限定公開ネットワーク アクセスの仕様では、2 種類のフェッチを区別していません。最終的には同じ制限が適用されます。
カバー写真: Markus Spiske（Unsplash）