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 specificatie voor lokale netwerktoegang . Het doel is om gebruikers te beschermen tegen CSRF-aanvallen (Cross-Site Request Forgery) die gericht zijn op routers en andere apparaten op privénetwerken, en om de mogelijkheid van websites om deze verzoeken te gebruiken om een ​​vingerafdruk van het lokale netwerk van de gebruiker te maken, te beperken.

Om te begrijpen hoe deze wijziging het webecosysteem beïnvloedt, is het Chrome-team op zoek naar 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. Vanuit Chrome 138 kunt u zich aanmelden voor deze nieuwe beperkingen door naar chrome://flags/#local-network-access-check en de vlag in te stellen op 'Ingeschakeld (blokkerend)'.

Wat is lokale netwerktoegang?

Lokale netwerktoegang beperkt de mogelijkheid van websites om verzoeken te sturen naar servers in het lokale netwerk van een gebruiker (inclusief servers die lokaal op de computer van de gebruiker draaien). De gebruiker moet hiervoor toestemming aan de site verlenen voordat dergelijke verzoeken kunnen worden ingediend. De mogelijkheid om deze toestemming aan te vragen is beperkt tot beveiligde contexten.

Een prompt met de tekst 'Zoek en maak verbinding met een apparaat in uw lokale netwerk.'
Voorbeeld van de toestemmingprompt voor lokale netwerktoegang in Chrome.

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

Welke soorten verzoeken worden hierdoor getroffen?

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

Een lokaal netwerk is een bestemming die verwijst naar de privéadresruimte die is gedefinieerd in sectie 3 van RFC1918 in IPv4 (bijvoorbeeld 192.168.0.0/16 ), een via IPv4 toegewezen IPv6-adres waarbij het toegewezen IPv4-adres zelf privé is, of een IPv6-adres buiten de subnetten ::1/128 , 2000::/3 en ff00::/8 .

Loopback is elke bestemming die verwijst naar de "loopback"-ruimte ( 127.0.0.0/8 ) zoals gedefinieerd in sectie 3.2.1.3 van RFC1122 van IPv4, de "link-local"-ruimte ( 169.254.0.0/16 ) zoals gedefinieerd in RFC3927 van IPv4, het "Unique Local Address"-prefix ( fcc00::/7 ) zoals gedefinieerd in sectie 3 van RFC4193 van IPv6, of het "link-local"-prefix ( fe80::/10 ) zoals gedefinieerd in sectie 2.5.6 van RFC4291 van IPv6.

Zie de tabel in de specificatie voor lokale netwerktoegang voor een volledige toewijzing van IP-adressen aan adresruimten.

Een openbaar netwerk is een andere bestemming.

Omdat de toegangsrechten voor het lokale netwerk beperkt zijn tot beveiligde contexten en het lastig kan zijn om lokale netwerkapparaten naar HTTPS te migreren, worden de verzoeken met toestemmingsgated toegang tot het lokale netwerk nu vrijgesteld van controles op gemengde inhoud als Chrome weet dat de verzoeken naar het lokale netwerk gaan voordat de bestemming wordt verwerkt. Chrome weet dat een verzoek naar het lokale netwerk gaat als:

  • De aangevraagde hostnaam is een letterlijk privé-IP-adres (bijv. 192.168.0.1 ).
  • De aangevraagde hostnaam is een .local domein.
  • De fetch() -aanroep is geannoteerd met de optie 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

Chroom 138

Onze eerste versie van Local Network Access 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 Local Network Access voor verzoeken die worden geïnitieerd via de JavaScript fetch() API, het laden van subresources en subframenavigatie.

Er is een demosite beschikbaar op https://lna-testing.notyetsecure.com/ voor het activeren van verschillende vormen van lokale netwerkverzoeken.

Bekende problemen en beperkingen

  • WebSockets ( crbug.com/421156866 ), WebTransport ( crbug.com/421216834 ) en WebRTC ( crbug.com/421223919 ) verbindingen met het lokale netwerk zijn nog niet gereguleerd door de LNA-machtiging.
  • Voor lokale netwerkaanvragen van Service Workers en Shared Workers is het vereist dat de oorsprong van de worker eerder de machtiging Lokale netwerktoegang heeft gekregen.
    • Als uw applicatie lokale netwerkverzoeken doet vanuit een service worker, moet u apart een lokale netwerkverzoek vanuit uw applicatie triggeren 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

We zijn van plan om Local Network Access zo snel mogelijk te implementeren. 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 implementeren. Dit zou een duidelijker migratiepad moeten bieden voor ontwikkelaars, vooral als u afhankelijk bent van toegang tot lokale netwerkbronnen via HTTP (aangezien deze verzoeken zouden worden geblokkeerd als gemengde content indien aangevraagd vanaf een HTTPS-pagina in browsers die de uitzondering voor gemengde content voor Local Network Access nog niet ondersteunen).

We voegen ook een Chrome-bedrijfsbeleid toe om te bepalen welke sites wel en niet lokale netwerkverzoeken kunnen indienen (door de toestemming voor die sites vooraf te verlenen of te weigeren). Hierdoor kunnen beheerde Chrome-installaties, zoals die in zakelijke omgevingen, de waarschuwing voor bekende beoogde use cases vermijden of sites verder blokkeren en helemaal geen toestemming meer kunnen vragen.

We zijn van plan om de machtiging voor lokale netwerktoegang verder te integreren met verschillende functies die verzoeken naar het lokale netwerk kunnen sturen. Zo zijn we van plan om binnenkort lokale netwerktoegang te leveren 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 over de ontwikkeling van Private Network Access was enorm waardevol voor onze nieuwe aanpak van Local Network Access. We willen iedereen die ons de afgelopen jaren heeft geholpen, nogmaals bedanken.

Als u een website ontwikkelt of gebruikt die afhankelijk is van verbindingen met het lokale netwerk van de gebruiker of van software die lokaal op de computer van de gebruiker draait, is het Chrome-team geïnteresseerd in uw feedback en use cases. U kunt op twee manieren helpen: