Nieuwe toestemmingsprompt voor lokale netwerktoegang

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 conceptspecificatie 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.

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 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 ) gedefinieerd in sectie 3.2.1.3 van RFC1122 van IPv4, de "link-local"-ruimte ( 169.254.0.0/16 ) gedefinieerd in RFC3927 van IPv4, het "Unique Local Address"-prefix ( fcc00::/7 ) gedefinieerd in sectie 3 van RFC4193 van IPv6, of het "link-local"-prefix ( fe80::/10 ) gedefinieerd in sectie 2.5.6 van RFC4291 van IPv6.

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 toestemmingsafhankelijke lokale netwerkverzoeken 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 persoonlijk 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 (Blokkeren)'. 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://local-network-access-testing.glitch.me/ voor het activeren van verschillende vormen van lokale netwerkverzoeken.

Bekende problemen en beperkingen

• De nieuwe toestemmingsprompt is momenteel alleen geïmplementeerd op Chrome voor desktop. We werken actief aan de portering ervan naar Android Chrome. (Bijgehouden op crbug.com/400455013 .)
• WebSockets ( crbug.com/421156866 ), WebTransport ( crbug.com/421216834 ) en WebRTC ( crbug.com/421223919 ) verbindingen met het lokale netwerk zijn nog niet geblokkeerd op basis van de LNA-machtiging.
• Voor lokale netwerkaanvragen van serviceworkers is momenteel vereist dat de oorsprong van de serviceworker eerder de machtiging Lokale netwerktoegang heeft gekregen.
  • Als uw applicatie lokale netwerkverzoeken doet vanuit een service worker, moet u momenteel een apart lokaal netwerkverzoek vanuit uw applicatie activeren 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

Ons doel is 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 van 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.

Naarmate we dichterbij de volledige lancering van lokale netwerktoegang in Chrome komen, delen we meer informatie.

Feedback gewenst

Eerdere feedback over de ontwikkeling van Private Network Access was enorm waardevol voor onze nieuwe aanpak van Local Network Access-machtigingen. 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 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:

• Ga naar chrome://flags#local-network-access-check , stel de vlag in op 'Ingeschakeld (blokkerend)' en kijk of uw website de nieuwe toestemmingsprompt correct activeert (en werkt zoals verwacht nadat u de toestemming hebt verleend).
• Als je problemen ondervindt of feedback hebt, meld dit dan via de Chromium Issue Tracker of via onze LNA-uitleg GitHub-repository . Chrome hoort graag van je.