更新
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 の使用をより強く推奨する方向に進むにつれて、安全でないコンテキストではウェブ プラットフォームの機能にアクセスできなくなる可能性が高いことを考慮すると、特に価値があると考えられます。プライベート ネットワーク アクセスに関係なく、これは賢明な投資である可能性があります。
Chrome 96 では、WebTransport over HTTP/3 のリリースが予定されています（オリジン トライアルが開始されています）。これには、鍵の共有やその他の標準を下回るセキュリティ対策から保護するための緩和策が組み込まれています。
- 固定された証明書の最大有効期限が短い。
- 不正使用の対象となった特定のキーを取り消すためのブラウザ固有のメカニズム。
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 より）