Veröffentlicht am 9. Juni 2025
Chrome fügt einen neuen Berechtigungs-Prompt für Websites hinzu, die im Rahmen der Spezifikation für den Zugriff auf das lokale Netzwerk Verbindungen zum lokalen Netzwerk eines Nutzers herstellen. Ziel ist es, Nutzer vor CSRF-Angriffen (Cross-Site Request Forgery) zu schützen, die auf Router und andere Geräte in privaten Netzwerken ausgerichtet sind, und die Möglichkeit von Websites einzuschränken, diese Anfragen zu verwenden, um das lokale Netzwerk des Nutzers zu identifizieren.
Um zu verstehen, wie sich diese Änderung auf das Web-Ökosystem auswirkt, bittet das Chrome-Team Entwickler, die Webanwendungen erstellen, die Verbindungen zum lokalen Netzwerk eines Nutzers oder zu Software herstellen, die lokal auf dem Computer des Nutzers ausgeführt wird, um Feedback. Ab Chrome 138 können Sie diese neuen Einschränkungen aktivieren, indem Sie chrome://flags/#local-network-access-check
aufrufen und das Flag auf „Aktiviert (Blockierung)“ festlegen.
Was ist der Zugriff auf das lokale Netzwerk?
Zugriff auf das lokale Netzwerk schränkt die Möglichkeit von Websites ein, Anfragen an Server im lokalen Netzwerk eines Nutzers zu senden (einschließlich Servern, die lokal auf dem Computer des Nutzers ausgeführt werden). Der Nutzer muss der Website die Berechtigung erteilen, bevor solche Anfragen gestellt werden können. Die Möglichkeit, diese Berechtigung anzufordern, ist auf sichere Kontexte beschränkt.
Viele andere Plattformen wie Android, iOS und MacOS haben eine Berechtigung für den Zugriff auf das lokale Netzwerk. Möglicherweise haben Sie der Google Home App diese Berechtigung für den Zugriff auf das lokale Netzwerk gewährt, als Sie neue Google TV- und Chromecast-Geräte eingerichtet haben.
Welche Arten von Anfragen sind betroffen?
Für den ersten Meilenstein des Zugriffs auf ein lokales Netzwerk betrachten wir eine „Anfrage an ein lokales Netzwerk“ als jede Anfrage aus dem öffentlichen Netzwerk an ein lokales Netzwerk oder ein Loopback-Ziel.
Ein lokales Netzwerk ist jedes Ziel, das in IPv4 in den privaten Adressbereich aufgelöst wird, der in Abschnitt 3 von RFC1918 definiert ist (z.B. 192.168.0.0/16
), eine IPv4-zugeordnete IPv6-Adresse, bei der die zugeordnete IPv4-Adresse selbst privat ist, oder eine IPv6-Adresse außerhalb der Subnetze ::1/128
, 2000::/3
und ff00::/8
.
Loopback ist jedes Ziel, das in den in Abschnitt 3.2.1.3 von RFC1122 für IPv4 definierten „Loopback“-Bereich (127.0.0.0/8
), den in RFC3927 für IPv4 definierten „Link-Local“-Bereich (169.254.0.0/16
), das in Abschnitt 3 von RFC4193 für IPv6 definierte Präfix „Unique Local Address“ (fcc00::/7
) oder das in Abschnitt 2.5.6 von RFC4291 für IPv6 definierte Präfix „Link-Local“ (fe80::/10
) aufgelöst wird.
Eine vollständige Zuordnung von IP-Adressen zu Adressräumen finden Sie in der Tabelle in der Spezifikation für den Zugriff auf das lokale Netzwerk.
Ein öffentliches Netzwerk ist jedes andere Ziel.
Da die Berechtigung für den Zugriff auf das lokale Netzwerk auf sichere Kontexte beschränkt ist und die Migration lokaler Netzwerkgeräte zu HTTPS schwierig sein kann, werden die durch Berechtigungen geschützten Anfragen an das lokale Netzwerk jetzt von Prüfungen auf gemischte Inhalte ausgenommen, wenn Chrome weiß, dass die Anfragen an das lokale Netzwerk gesendet werden, bevor das Ziel aufgelöst wird. Chrome erkennt, dass eine Anfrage an das lokale Netzwerk gesendet wird, wenn:
- Der Hostname der Anfrage ist ein privates IP-Literal (z.B.
192.168.0.1
). - Der Hostname der Anfrage ist eine
.local
-Domain. - Der
fetch()
-Aufruf ist mit der OptiontargetAddressSpace: "local".
annotiert.
// Example 1: Private IP literal is exempt from mixed content.
fetch("http://192.168.0.1/ping");
// Example 2: `.local` domain is exempt from mixed content.
fetch("http://router.local/ping");
// Example 3: Public domain is not exempt from mixed content,
// even if it resolves to a local network address.
fetch("http://example.com/ping");
// Example 4: Adding the `targetAddressSpace` option flags that
// the request will go to the local network, and is thus exempt
// from mixed content.
fetch("http://example.com/ping", {
targetAddressSpace: "local",
});
Änderungen in Chrome
Chrome 138
Die erste Version des Zugriffs auf das lokale Netzwerk kann in Chrome 138 getestet werden. Nutzer können den neuen Berechtigungs-Prompt aktivieren, indem sie chrome://flags#local-network-access-check
auf „Aktiviert (blockierend)“ festlegen. Dadurch wird das Auslösen der Aufforderung zur Berechtigung für den Zugriff auf das lokale Netzwerk für Anfragen unterstützt, die über die JavaScript-API fetch()
, das Laden von untergeordneten Ressourcen und die Navigation von untergeordneten Frames initiiert werden.
Unter https://lna-testing.notyetsecure.com/ ist eine Demowebsite verfügbar, auf der verschiedene Arten von Anfragen an das lokale Netzwerk ausgelöst werden können.
Bekannte Probleme und Beschränkungen
- WebSockets (crbug.com/421156866), WebTransport (crbug.com/421216834) und WebRTC-Verbindungen (crbug.com/421223919) zum lokalen Netzwerk sind noch nicht durch die Berechtigung für den Zugriff auf das lokale Netzwerk geschützt.
- Für Anfragen an das lokale Netzwerk von Service Workern und Shared Workers muss dem Ursprung des Workers zuvor die Berechtigung für den Zugriff auf das lokale Netzwerk erteilt worden sein.
- Wenn Ihre Anwendung lokale Netzwerkanfragen von einem Service Worker aus stellt, müssen Sie separat eine lokale Netzwerkanfrage von Ihrer Anwendung aus auslösen, um die Berechtigungsaufforderung zu starten. Wir arbeiten an einer Möglichkeit, dass Mitarbeiter die Berechtigungsaufforderung auslösen können, wenn ein aktives Dokument verfügbar ist. Weitere Informationen finden Sie unter crbug.com/404887282.
Chrome 139 und höher
Wir möchten den Zugriff auf das lokale Netzwerk so schnell wie möglich anbieten. Da einige Websites möglicherweise mehr Zeit benötigen, um mit Anmerkungen zum Zugriff auf das lokale Netzwerk aktualisiert zu werden, werden wir ein Origin Trial hinzufügen, damit Websites die Anforderung für sichere Kontexte vorübergehend deaktivieren können, bevor wir den Zugriff auf das lokale Netzwerk standardmäßig einführen. Dies sollte Entwicklern einen klareren Migrationspfad bieten, insbesondere wenn Sie auf den Zugriff auf lokale Netzwerkressourcen über HTTP angewiesen sind. Diese Anfragen würden als gemischte Inhalte blockiert, wenn sie von einer HTTPS-Seite in Browsern angefordert werden, die die Ausnahme für gemischte Inhalte für den Zugriff auf das lokale Netzwerk noch nicht unterstützen.
Außerdem fügen wir eine Chrome-Unternehmensrichtlinie hinzu, mit der gesteuert werden kann, welche Websites Anfragen an das lokale Netzwerk stellen dürfen und welche nicht. Die Berechtigung für diese Websites kann also vorab erteilt oder verweigert werden. So kann bei verwalteten Chrome-Installationen, z. B. in Unternehmen, die Warnung für bekannte Anwendungsfälle vermieden oder Websites können daran gehindert werden, die Berechtigung überhaupt anzufordern.
Wir planen, die Berechtigung „Zugriff auf das lokale Netzwerk“ weiterhin in verschiedene Funktionen zu integrieren, die Anfragen an das lokale Netzwerk senden können. Wir planen beispielsweise, den lokalen Netzwerkzugriff für WebSockets-, WebTransport- und WebRTC-Verbindungen bald einzuführen.
Wir werden weitere Informationen bereitstellen, sobald wir den lokalen Netzwerkzugriff in Chrome vollständig einführen können.
Wir freuen uns über Ihr Feedback
Das bisherige Feedback zur Entwicklung des privaten Netzwerkzugriffs war sehr wertvoll und hat uns bei der Entwicklung unseres neuen Ansatzes für die Berechtigung „Zugriff auf lokales Netzwerk“ geholfen. Wir möchten uns noch einmal bei allen bedanken, die sich über die Jahre hinweg beteiligt haben.
Wenn Sie eine Website entwickeln oder nutzen, die Verbindungen zum lokalen Netzwerk des Nutzers oder zu Software herstellt, die lokal auf dem Computer des Nutzers ausgeführt wird, freut sich das Chrome-Team über Ihr Feedback und Ihre Anwendungsfälle. Sie haben zwei Möglichkeiten, uns zu helfen:
- Rufen Sie
chrome://flags#local-network-access-check
auf, stellen Sie das Flag auf „Aktiviert (Blockierung)“ ein und prüfen Sie, ob auf Ihrer Website die neue Berechtigungsaufforderung korrekt ausgelöst wird und ob die Website wie erwartet funktioniert, nachdem Sie die Berechtigung erteilt haben. - Wenn Sie Probleme haben oder Feedback geben möchten, reichen Sie ein Problem im Chromium Issue Tracker oder in unserem GitHub-Repository für die LNA-Spezifikation ein. Wir freuen uns über Feedback zu Chrome.