Nieuwe toestemmingsprompt voor lokale netwerktoegang

Chris Thompson
Chris Thompson

Gepubliceerd: 9 juni 2025

Chrome voegt een nieuwe toestemmingsprompt toe voor websites die verbinding maken met het lokale netwerk van een gebruiker, als onderdeel van de Local Network Access-specificatie . Het doel is om gebruikers te beschermen tegen CSRF-aanvallen (cross-site request forgery) gericht op routers en andere apparaten in privénetwerken, en om te voorkomen dat websites deze verzoeken gebruiken om het lokale netwerk van de gebruiker te identificeren.

Om te begrijpen hoe deze verandering het webecosysteem beïnvloedt, vraagt ​​het Chrome-team feedback van ontwikkelaars die webapplicaties bouwen die afhankelijk zijn van verbindingen met het lokale netwerk van een gebruiker of met software die lokaal op de computer van de gebruiker draait. Vanaf Chrome 138 kunt u zich aanmelden voor deze nieuwe beperkingen door naar chrome://flags/#local-network-access-check te gaan en de vlag in te stellen op "Ingeschakeld (Blokkeren)".

Wat is lokale netwerktoegang?

Lokale netwerktoegang beperkt de mogelijkheid voor websites om verzoeken te verzenden naar servers op het lokale netwerk van een gebruiker (inclusief servers die lokaal op de computer van de gebruiker draaien). De gebruiker moet de website toestemming geven voordat dergelijke verzoeken kunnen worden verzonden. De mogelijkheid om deze toestemming aan te vragen is beperkt tot beveiligde omgevingen.

Een melding met de tekst 'Zoek naar en maak verbinding met een apparaat in uw lokale netwerk.'
Voorbeeld van de Chrome-prompt voor toegang tot het lokale netwerk.

Veel andere platforms, zoals Android , iOS en macOS, hebben een machtiging voor toegang tot het lokale netwerk. Zo heb je deze machtiging bijvoorbeeld mogelijk verleend aan de Google Home-app bij het instellen van nieuwe Google TV- en Chromecast-apparaten.

Welke soorten verzoeken worden hierdoor beïnvloed?

Voor de eerste mijlpaal van lokale netwerktoegang beschouwen we een "lokaal netwerkverzoek" als elk verzoek van het openbare netwerk naar een lokaal netwerk of loopback-bestemming.

Een lokaal netwerk is elke bestemming die verwijst naar adressen die gereserveerd zijn voor lokaal gebruik. Voorbeelden hiervan zijn privé-IPv4-adressen zoals gespecificeerd in sectie 3 van RFC1918 (bijv. 192.168.0.0/16 ), het IPv4-prefix "link-local" ( 169.254.0.0/16 ) zoals gedefinieerd in RFC3927 , het IPv6-prefix "Unique Local Address" ( fc00::/7 ) zoals gedefinieerd in sectie 3 van RFC4193 , het IPv6-prefix "link-local" ( fe80::/10 ) zoals gedefinieerd in sectie 2.5.6 van RFC4291 , of een IPv4-gemapt IPv6-adres ( ::ffff:0:0/96 ) waarbij het gemapte IPv4-adres zelf lokaal is.

Loopback is elke bestemming die verwijst naar de lokale machine (d.w.z. de "loopback"-interface), zoals het IPv4-loopbackprefix ( 127.0.0.0/8 ) gedefinieerd in sectie 3.2.1.3 van RFC1122 , of het IPv6-loopbackprefix ( ::1/128 ) gedefinieerd in sectie 2.5.3 van RFC4291 .

Voor een volledig overzicht van de toewijzing van IP-adressen aan adresruimten, zie de tabel in de Local Network Access-specificatie .

Een openbaar netwerk is elke andere bestemming.

Omdat de toegang tot het lokale netwerk beperkt is tot beveiligde contexten en het lastig kan zijn om apparaten in een lokaal netwerk naar HTTPS te migreren, worden lokale netwerkverzoeken met beperkte toegang nu vrijgesteld van controles op gemengde inhoud als Chrome weet dat de verzoeken naar het lokale netwerk gaan voordat de bestemming wordt bepaald. Chrome weet dat een verzoek naar het lokale netwerk gaat als:

  • De hostnaam van het verzoek is een privé-IP-adres (bijvoorbeeld 192.168.0.1 ).
  • De hostnaam van het verzoek is een .local domein.
  • De fetch() -aanroep is voorzien van de annotatie targetAddressSpace: "local". 
// 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",
});

Wat verandert er in Chrome?

Chrome 138

Onze eerste versie van Lokale netwerktoegang is klaar voor opt-in testen in Chrome 138. Gebruikers kunnen de nieuwe toestemmingsprompt inschakelen door chrome://flags#local-network-access-check in te stellen op "Ingeschakeld (Blokkerend)". Dit ondersteunt het activeren van de toestemmingsprompt voor Lokale netwerktoegang voor verzoeken die worden geïnitieerd met behulp van de JavaScript fetch() API, het laden van subbronnen en navigatie binnen subframes.

Een demosite is beschikbaar op https://lna-testing.notyetsecure.com/ om verschillende soorten lokale netwerkverzoeken te simuleren.

Bekende problemen en beperkingen

  • WebSocket- ( crbug.com/421156866 ), WebTransport- ( crbug.com/421216834 ) en WebRTC-verbindingen ( crbug.com/421223919 ) met het lokale netwerk zijn nog niet onderworpen aan de LNA-toestemming.
  • Verzoeken om toegang tot het lokale netwerk van servicemedewerkers en gedeelde medewerkers vereisen dat de locatie van de medewerker vooraf toestemming heeft gekregen voor toegang tot het lokale netwerk.
    • Als uw applicatie lokale netwerkverzoeken vanuit een service worker uitvoert, moet u afzonderlijk een lokaal netwerkverzoek vanuit uw applicatie initiëren om de toestemmingsprompt te activeren. (We werken aan een manier waarop workers de toestemmingsprompt kunnen activeren als er een actief document beschikbaar is — zie crbug.com/404887282 .)

Chrome 139 en verder

Het is onze bedoeling om Local Network Access zo snel mogelijk uit te rollen. Omdat sommige sites mogelijk meer tijd nodig hebben om te worden bijgewerkt met Local Network Access-annotaties, voegen we een Origin Trial toe waarmee sites tijdelijk kunnen afzien van de vereiste voor beveiligde contexten voordat we Local Network Access standaard uitrollen. Dit zou een duidelijker migratiepad moeten bieden voor ontwikkelaars, met name als u afhankelijk bent van toegang tot lokale netwerkbronnen via HTTP (aangezien deze verzoeken zouden worden geblokkeerd als gemengde inhoud als ze worden aangevraagd vanaf een HTTPS-pagina in browsers die de uitzondering voor gemengde inhoud van Local Network Access nog niet ondersteunen).

We voegen ook een Chrome-bedrijfsbeleid toe waarmee kan worden bepaald welke sites wel en niet lokale netwerkverzoeken mogen doen (door de toestemming vooraf te verlenen of te weigeren). Hierdoor kunnen beheerde Chrome-installaties, zoals die in bedrijfsomgevingen, de waarschuwing voor bekende gebruiksscenario's overslaan of sites volledig blokkeren zodat ze geen toestemming meer kunnen aanvragen.

We zijn van plan de machtiging 'Lokale netwerktoegang' verder te integreren met verschillende functies die verzoeken naar het lokale netwerk kunnen verzenden. Zo willen we binnenkort 'Lokale netwerktoegang' beschikbaar stellen voor WebSockets-, WebTransport- en WebRTC-verbindingen.

We zullen meer informatie delen naarmate we dichter bij de volledige lancering van Lokale netwerktoegang in Chrome komen.

Feedback gewenst

Eerdere feedback op de ontwikkeling van toegangsrechten voor privénetwerken was ontzettend waardevol en heeft ons geholpen bij het ontwikkelen van onze nieuwe toegangsrechten voor lokale netwerken. We willen iedereen die hier de afgelopen jaren bij betrokken is geweest, nogmaals hartelijk bedanken.

Als u een website ontwikkelt of gebruikt die afhankelijk is van verbindingen met het lokale netwerk van de gebruiker of software die lokaal op de computer van de gebruiker draait, dan is het Chrome-team geïnteresseerd in uw feedback en gebruiksscenario's. Er zijn twee dingen die u kunt doen om te helpen: