Chrome 124 には、混合コンテンツを緩和するプライベート ネットワーク アクセス権限が含まれています。この変更に対応するためにさらに時間が必要なサイト向けの非推奨トライアルが進行中です。このトライアルは Chrome 126 で終了し、2024 年 9 月 4 日にリリースされる予定です。この投稿では、変更点、機能の設計、現在のウェブサイトの移行方法、実装のテスト方法について詳しく説明します。
変更内容
グローバルに一意の名前がなく、TLS 証明書を取得できないプライベート ネットワーク上のデバイスへの接続を確立するために、この機能では、fetch() に新しいオプションを導入し、そのようなデバイスと通信するデベロッパーのインテントを宣言します。これには、この機能に対する各サイトのアクセスを制御する新しいポリシー制御機能と、追加のメタデータを提供するサーバーのプリフライト レスポンス用の新しいヘッダーが含まれています。
プライベート ネットワーク アクセスとは
プライベート ネットワーク アクセス（PNA、旧称 CORS-RFC1918、略してローカル ネットワーク アクセス）は、プライベート ネットワーク上のサーバーにリクエストを送信するウェブサイトの機能を制限するセキュリティ機能です。これにより、クロスサイト リクエスト フォージェリ（CSRF）などの潜在的な攻撃からユーザーと内部ネットワークを保護できます。Chrome では PNA を段階的に実装してきましたが、今後のリリースで保護を拡大する予定です。
権限プロンプトが必要な理由
Chrome 94 では、保護されていない公開ウェブサイトからのプライベート ネットワーク アクセスのブロックが導入されました。現在実施中の セキュアでないコンテキストからのプライベート ネットワーク アクセスの非推奨トライアルにより、影響を受けたウェブサイトを HTTPS に移行するうえでの課題が明らかになりました。一般的な懸念は、プライベート デバイスを HTTPS に移行することが困難で、混合コンテンツ チェック違反が発生することです。
この課題に対処するため、Chrome 120 からはオリジン トライアルに、Chrome 124 からは安定版で、新しい権限プロンプトが追加されました。
権限プロンプトが必要になるのはどのような場合ですか？
非セキュア コンテキストの非推奨トライアルは、権限プロンプト機能が利用可能になってから数マイルストーン後に終了する予定です。互換性を確保するには、公開ウェブサイトを HTTPS に移行する必要があります。プライベート サーバーを HTTPS に移行できない場合、新しい権限プロンプト機能を使用すると、混合コンテンツのチェックを緩和できます。
権限プロンプトを使用したプライベート ネットワーク アクセス リクエストの一般的なワークフローは次のとおりです。
権限プロンプトをトリガーする
新しい targetAddressSpace 属性を取得オプションとして追加すると、リクエストで混合コンテンツのチェックをスキップできます。
fetch("http://router.local/ping", {
targetAddressSpace: "private",
});
プライベート ネットワーク アクセス: プリフライトの導入によると、プライベート ネットワーク リクエストの前にプリフライト リクエストがあります。このプリフライト リクエストには新しいヘッダー Access-Control-Request-Private-Network: true が含まれ、対応するレスポンスにはヘッダー Access-Control-Allow-Private-Network: true が含まれている必要があります。
新しい権限プロンプトに対応するため、デバイスは 2 つの新しいレスポンス ヘッダー Private-Network-Access-Name と Private-Network-Access-ID を組み込む必要があります。
Private-Network-Access-ID: コロンで区切られた 6 16 進バイトで表される 48 ビット値。Private-Network-Access-Name: ECMAScript 正規表現/^[a-z0-9_-.]+$/.に一致する文字列として有効な名前。名前の最大長は UTF-8 コード単位 248 です。
Private-Network-Access-Name: "My Smart Toothbrush"
Private-Network-Access-ID: "01:23:45:67:89:0A"
デモ
デモは https://private-network-access-permission-test.glitch.me/ で確認できます。
デモ用ウェブサイトを使用するには、個人用のプライベート サーバーを起動する必要があります。プライベート サーバーは、HTTP ヘッダー Access-Control-Allow-Private-Network: true と、サーバー指定のヘッダー Private-Network-Access-ID および Private-Network-Access-Name で応答する必要があります。すべてが正しく設定されていれば、次の権限プロンプトが表示されます。
セキュアでないコンテキストの非推奨トライアルを終了する
セキュアでないコンテキスト向けのプライベート ネットワーク アクセスの非推奨トライアルを登録したウェブサイトについては、このタイミングで新しい権限プロンプトを使用してウェブサイトを移行し、トライアルを終了してください。
コードを更新したら、HTML、JavaScript、または HTTP ヘッダー内のトライアル トークンを削除します。トライアル トークンをどこに配置したかわからない場合は、前回のブログ投稿の非推奨トライアルに登録するをご覧ください。
試用のページでもトークンを削除することもできます。
次のステップ
非 API fetch() からのリクエストについては、まだ調査中です。
Service Worker を使用する、または新しい Content-Security-Policy としてターゲット アドレス空間を作成するなど、いくつかのソリューションがテストされています。ただし、非 API の fetch() からのリクエストに関する最終的な形状については、現在も調査中です。
サブフレームからのリクエストは、将来的に権限ポリシーでサポートされる可能性があります。
将来的には、サブフレームの機能を緩和する権限ポリシーをサポートする可能性があります。
プライベート ネットワークのユースケースに関するフィードバック
ウェブサイトをプライベート ネットワークでホストし、パブリック ネットワークからのリクエストを必要とする場合は、Chrome チームがフィードバックをお寄せください。Chromium Issue Tracker（コンポーネント: Blink> [SecurityFeature] > [CORS] > [PrivateNetworkAccess]）または GitHub リポジトリで問題を提出します。