Chrome 124 には、混合コンテンツを緩和するためのプライベート ネットワーク アクセス権機能が含まれています。この変更への準備にさらに時間が必要なサイトについては、非推奨トライアルが実施されていますが、このトライアルは 2025 年 2 月 4 日にリリース予定の Chrome 132 で終了します。この記事では、この変更、機能の設計の詳細、現在のウェブサイトを移行する方法、実装をテストする方法について説明します。
変更内容
グローバルに一意の名前を持たず、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 を含める必要があります。
新しい権限プロンプトに対応するには、デバイスに Private-Network-Access-Name と Private-Network-Access-ID の 2 つの新しいレスポンス ヘッダーを組み込む必要があります。
Private-Network-Access-ID: コロンで区切られた 6 バイトの 16 進数で表される 48 ビットの値。Private-Network-Access-Name: ECMAScript 正規表現/^[a-z0-9_-.]+$/.に一致する文字列として有効な名前。名前の最大長は 248 UTF-8 コード単位です。
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() からのリクエストに対するソリューションは現在調査中です。
サービス ワーカーの使用や、ターゲット アドレス空間を新しい Content-Security-Policy にするなど、いくつかのソリューションがテストされています。ただし、API 以外の fetch() からのリクエストの最終的な形状はまだ調査中です。
サブフレームからのリクエストは、今後権限ポリシーでサポートされる可能性があります。
今後、権限ポリシーをサポートして、サブフレームの機能を緩和する可能性があります。
プライベート ネットワークのユースケースに関するフィードバック
パブリック ネットワークからのリクエストを必要とするプライベート ネットワークにウェブサイトをホストしている場合は、Chrome チームにフィードバックをお寄せください。Chromium Issue Tracker（コンポーネント: Blink> SecurityFeature> CORS> PrivateNetworkAccess）または GitHub リポジトリで問題を報告します。