Chromes Local Network Access (LNA) Berechtigung erklärt

Sie testen eine Web-App, die mit einer lokalen API kommuniziert, einem Dev-Server auf Port 3000 oder einem Hardware-Gerät in Ihrem Netzwerk. Plötzlich zeigt Chrome einen Dialog an: „[Website] möchte nach Geräten in Ihrem lokalen Netzwerk suchen und sich mit ihnen verbinden.” Sie haben das nicht erwartet. Hier erfahren Sie genau, was passiert und warum.

Was ist die Chrome Local Network Access Berechtigung?

Chrome’s Local Network Access (LNA) ist eine Browser-Sicherheitsänderung, die verhindert, dass öffentliche Websites unbemerkt Anfragen an Geräte in Ihrem lokalen Netzwerk senden. Ab Chrome 142 schützt der Browser diese Anfragen durch eine explizite Berechtigungsabfrage für Benutzer.

Vor LNA konnte jede Website, die Sie besuchten, Ihren Browser als Proxy verwenden, um unbemerkt Ihren Router, Drucker, lokale API oder jedes andere Gerät in Ihrem Netzwerk zu scannen – ohne dass Sie es wussten. Das ist ein realer Angriffsvektor. Eine bösartige Website könnte dies ausnutzen, um Cross-Site Request Forgery (CSRF) gegen anfällige lokale Geräte durchzuführen oder die Topologie Ihres Netzwerks zu fingerprinting.

LNA schließt diese Lücke, indem zuerst die Zustimmung des Benutzers erforderlich ist.

Dies ersetzt einen früheren Versuch namens Private Network Access (PNA), der auf serverseitigen CORS-Preflights basierte und erforderte, dass lokale Geräte sich explizit anmelden. Dieser Ansatz scheiterte, weil die Aktualisierung der Firmware auf Millionen von Routern und IoT-Geräten unpraktisch ist. LNA verlagert die Verantwortung stattdessen auf Websites, die viel einfacher zu aktualisieren sind.

Weitere Hintergrundinformationen finden Sie im offiziellen Chrome-Sicherheitsupdate zu Local Network Access Einschränkungen.

Was löst die Chrome Local Network Access Berechtigungsabfrage aus?

Die Abfrage erscheint, wenn eine Seite von einem öffentlichen Origin versucht, ein lokales oder Loopback-Ziel zu erreichen. Chrome definiert drei Adressräume:

Jede Anfrage, die von öffentlich → lokal oder öffentlich → loopback übergeht, löst LNA aus. Häufige Entwicklerszenarien, die davon betroffen sind:

• Eine gehostete Web-App, die http://192.168.1.1/api aufruft
• Ein Cloud-Dashboard, das sich mit einem lokal laufenden Agenten auf localhost:8080 verbindet
• Eine Geräte-Setup-Seite (bereitgestellt von der öffentlichen Website eines Herstellers), die mit Hardware in Ihrem LAN kommuniziert
• Eine ZTNA- oder VPN-Lösung, die Traffic durch IPv6-Bereiche leitet, die Chrome als lokal klassifiziert (wie fc00::/7)

Wichtige Einschränkungen, die Entwickler kennen müssen

Nur sichere Kontexte. Die LNA-Berechtigung kann nur von HTTPS-Seiten angefordert werden. Da lokale Geräte jedoch oft kein HTTPS bereitstellen können, kann Chrome die Mixed-Content-Einschränkungen für eindeutig lokale Ziele nach Erteilung der Berechtigung lockern, da viele Geräte nur HTTP-Endpunkte bereitstellen.

// Chrome weiß, dass dies lokal ist — Mixed-Content-Prüfung ausgenommen
fetch("http://192.168.0.1/ping");

// Chrome weiß durch Annotation, dass dies lokal ist
fetch("http://mydevice.example.com/ping", { targetAddressSpace: "local" });

// Chrome weiß NICHT, dass dies lokal ist, bis DNS aufgelöst wird — nicht ausgenommen
fetch("http://example.com/ping");

Worker benötigen spezielle Behandlung. Service Workers und Shared Workers erfordern, dass dem übergeordneten Origin bereits die LNA-Berechtigung erteilt wurde, bevor sie lokale Netzwerkanfragen stellen können. Es gibt keine Möglichkeit für einen Worker, die Abfrage direkt auszulösen.

Iframes erfordern Delegation. Eingebettete Frames benötigen eine explizite Berechtigungsdelegation über die Permissions Policy (local-network-access), um lokale Netzwerkanfragen zu stellen.

WebTransport und WebRTC sind noch nicht von der LNA-Beschränkung abgedeckt – Unterstützung wird in zukünftigen Chrome-Versionen erwartet. WebSocket-Verbindungen zu lokalen Adressen folgen denselben Local Network Access Einschränkungen wie andere Netzwerkanfragen.

Warum das wichtiger ist, als es aussieht

Die Chrome Local Network Security Änderung bringt den Browser in Einklang mit dem, was iOS, Android und macOS seit Jahren auf OS-Ebene tun. Apps auf diesen Plattformen fragen bereits nach lokalem Netzwerkzugriff. Chrome zieht nach.

Für Entwickler, die vom Browser aus auf lokale Geräte zugreifen – sei es ein Dev-Server, eine Hardware-Schnittstelle oder ein lokaler Agent – ist die praktische Auswirkung klar: Ihre App muss jetzt die Berechtigungsabfrage absichtlich auslösen, den Fall behandeln, in dem ein Benutzer sie ablehnt, und sicherstellen, dass Anfragen aus einem sicheren Kontext stammen.

Fazit

Die Chrome Local Network Access Berechtigung ist eine bedeutende Veränderung in der Art und Weise, wie Browser die Grenze zwischen dem öffentlichen Web und Ihrem privaten Netzwerk handhaben. Für Endbenutzer schließt sie einen langjährigen blinden Fleck. Für Entwickler führt sie eine neue Anforderung ein: Jede Seite mit öffentlichem Origin, die in den lokalen Adressraum greift, muss nun eine explizite Berechtigungsschranke berücksichtigen.

Die Anpassung ist unkompliziert. Stellen Sie Ihre Seiten über HTTPS bereit, rechnen Sie mit Berechtigungsablehnungen in Ihrer Benutzeroberfläche, delegieren Sie den Zugriff an iframes über die Permissions Policy und testen Sie frühzeitig. Verwenden Sie chrome://flags/#local-network-access-check auf „Enabled (Blocking)” gesetzt, um genau zu sehen, was Chrome 142 Benutzer erleben werden. Je früher Sie sich anpassen, desto weniger Überraschungen werden Ihre Benutzer erleben.

FAQs

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.