Chrome 124 には、混合コンテンツを緩和するためのプライベート ネットワーク アクセス権機能が含まれています。この変更の準備にさらに時間を要するサイトに対して、デプリケーション トライアルが進行中です。ただし、このトライアルは Chrome 132 で終了し、2025 年 2 月 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
を含める必要があります。
新しい権限プロンプトに対応するには、デバイスに 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 リポジトリで問題を報告します。