Chrome の Local Network Access (LNA) パーミッションの解説

ローカル API、ポート 3000 で動作する開発サーバー、またはネットワーク上のハードウェアデバイスと通信する Web アプリをテストしているとします。突然 Chrome がダイアログを表示します:「[サイト] がローカルネットワーク上のデバイスを検索して接続しようとしています。」 予期していなかったことでしょう。ここでは、何が起こっているのか、そしてその理由を正確に説明します。

Chrome の Local Network Access パーミッションとは?

Chrome の Local Network Access (LNA) は、公開 Web サイトがローカルネットワーク上のデバイスに黙ってリクエストを送信することを防ぐブラウザセキュリティの変更です。Chrome 142 以降、ブラウザはこれらのリクエストを明示的なユーザーパーミッションプロンプトの背後でゲートします。

LNA 以前は、訪問した Web サイトはブラウザをプロキシとして使用し、ユーザーの知らないうちにルーター、プリンター、ローカル API、またはネットワーク上の他のデバイスを静かに探索できました。これは実際の攻撃ベクトルです。悪意のあるサイトは、脆弱なローカルデバイスに対して クロスサイトリクエストフォージェリ (CSRF) を実行したり、ネットワークトポロジをフィンガープリントしたりするために悪用できました。

LNA は、まずユーザーの同意を要求することで、このギャップを埋めます。

これは、サーバーサイド CORS プリフライトに依存し、ローカルデバイスが明示的にオプトインすることを要求していた Private Network Access (PNA) と呼ばれる以前の試みに代わるものです。このアプローチは、数百万のルーターや IoT デバイスのファームウェアを更新することが非現実的であるため、停滞しました。LNA は代わりに Web サイトに責任を移し、はるかに更新しやすくなっています。

詳細については、Local Network Access 制限に関する Chrome の公式セキュリティアップデートを参照してください。

Chrome Local Network Access パーミッションプロンプトをトリガーするものは?

プロンプトは、公開オリジンから提供されたページがローカルまたはループバック宛先にアクセスしようとしたときに表示されます。Chrome は 3 つのアドレス空間を定義しています:

公開 → ローカルまたは公開 → ループバックを横断するリクエストは LNA をトリガーします。これに該当する一般的な開発者シナリオ:

• http://192.168.1.1/api を呼び出すホストされた Web アプリ
• localhost:8080 でローカルに実行されているエージェントに接続するクラウドダッシュボード
• (メーカーの公開サイトから提供される) デバイスセットアップページが LAN 上のハードウェアと通信する
• Chrome がローカルとして分類する IPv6 範囲 (fc00::/7 など) を通じてトラフィックをルーティングする ZTNA または VPN ソリューション

開発者が知っておくべき主な制約

セキュアコンテキストのみ。 LNA パーミッションは HTTPS ページからのみリクエストできます。ただし、ローカルデバイスは多くの場合 HTTPS を提供できないため、Chrome はパーミッションが付与された後、明らかにローカルなターゲットに対して混合コンテンツ制限を緩和する場合があります。多くのデバイスは HTTP エンドポイントのみを公開しているためです。

// Chrome はこれがローカルであることを認識 — 混合コンテンツチェックが免除される
fetch("http://192.168.0.1/ping");

// Chrome はアノテーションによりこれがローカルであることを認識
fetch("http://mydevice.example.com/ping", { targetAddressSpace: "local" });

// Chrome は DNS が解決されるまでこれがローカルであることを認識しない — 免除されない
fetch("http://example.com/ping");

Worker には特別な処理が必要。 Service Worker と Shared Worker は、ローカルネットワークリクエストを行う前に、親オリジンがすでに LNA パーミッションを付与されている必要があります。Worker が直接プロンプトをトリガーする方法はありません。

iframe には委譲が必要。 埋め込まれたフレームがローカルネットワークリクエストを行うには、Permissions Policy (local-network-access) を介した明示的なパーミッション委譲が必要です。

WebTransport と WebRTC はまだ LNA ゲーティングの対象外です — 将来の Chrome リリースでサポートされる予定です。ローカルアドレスへの WebSocket 接続は、他のネットワークリクエストと同じローカルネットワークアクセス制限に従います。

これが見た目以上に重要な理由

Chrome のローカルネットワークセキュリティ変更は、iOS、Android、macOS が OS レベルで何年も前から行ってきたことにブラウザを合わせるものです。これらのプラットフォーム上のアプリは、すでにローカルネットワークアクセスを要求しています。Chrome は追いついているのです。

ブラウザからローカルデバイス (開発サーバー、ハードウェアインターフェース、ローカルエージェントなど) にアクセスする開発者にとって、実際的な影響は明確です: アプリは意図的にパーミッションプロンプトをトリガーし、ユーザーが拒否した場合を処理し、リクエストがセキュアコンテキストから発信されることを保証する必要があります。

まとめ

Chrome の Local Network Access パーミッションは、ブラウザが公開 Web とプライベートネットワークの境界をどのように処理するかにおける重要な変化です。エンドユーザーにとっては、長年の盲点を閉じるものです。開発者にとっては、新しい要件が導入されます: ローカルアドレス空間にアクセスする公開オリジンページは、明示的なパーミッションゲートを考慮する必要があります。

調整は簡単です。HTTPS でページを提供し、UI でパーミッション拒否を予測し、Permissions Policy を介して iframe にアクセスを委譲し、早期にテストします。chrome://flags/#local-network-access-check を “Enabled (Blocking)” に設定して、Chrome 142 ユーザーが体験するものを正確に確認してください。早く適応すればするほど、ユーザーが直面する驚きは少なくなります。

よくある質問

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.