Nouvelle invite d'autorisation pour l'accès au réseau local

Chris Thompson

Publié le 9 juin 2025

Chrome ajoute une nouvelle invite d'autorisation pour les sites qui établissent des connexions au réseau local d'un utilisateur dans le cadre de la spécification d'accès au réseau local. L'objectif est de protéger les utilisateurs contre les attaques par falsification de requêtes intersites (CSRF) ciblant les routeurs et d'autres appareils sur des réseaux privés, et de réduire la capacité des sites à utiliser ces requêtes pour identifier l'empreinte du réseau local de l'utilisateur.

Pour comprendre l'impact de ce changement sur l'écosystème Web, l'équipe Chrome recherche les commentaires des développeurs qui créent des applications Web qui s'appuient sur l'établissement de connexions au réseau local d'un utilisateur ou à un logiciel exécuté localement sur son ordinateur. À partir de Chrome 138, vous pouvez activer ces nouvelles restrictions en accédant à chrome://flags/#local-network-access-check et en définissant l'indicateur sur "Activé (Blocage)".

Qu'est-ce que l'accès au réseau local ?

Accès au réseau local : limite la capacité des sites Web à envoyer des requêtes aux serveurs sur le réseau local d'un utilisateur (y compris les serveurs exécutés localement sur la machine de l'utilisateur), ce qui nécessite que l'utilisateur accorde l'autorisation au site avant que ces requêtes puissent être effectuées. La possibilité de demander cette autorisation est limitée aux contextes sécurisés.

De nombreuses autres plates-formes, telles que Android, iOS et MacOS, disposent d'une autorisation d'accès au réseau local. Par exemple, vous avez peut-être accordé cette autorisation d'accès au réseau local à l'application Google Home lorsque vous avez configuré de nouveaux appareils Google TV et Chromecast.

Quels types de requêtes sont concernés ?

Pour le premier jalon de l'accès au réseau local, nous considérons qu'une "requête de réseau local" est toute requête à partir du réseau public vers un réseau local ou une destination de bouclage.

Un réseau local est toute destination qui se résout dans l'espace d'adressage privé défini dans la section 3 de la RFC1918 en IPv4 (par exemple, 192.168.0.0/16), une adresse IPv6 mappée en IPv4 où l'adresse IPv4 mappée est elle-même privée, ou une adresse IPv6 en dehors des sous-réseaux ::1/128, 2000::/3 et ff00::/8.

Le loopback est une destination qui se résout à l'espace "loopback" (127.0.0.0/8) défini dans la section 3.2.1.3 de la RFC1122 pour IPv4, à l'espace "link-local" (169.254.0.0/16) défini dans la RFC3927 pour IPv4, au préfixe "Unique Local Address" (fcc00::/7) défini dans la section 3 de la RFC4193 pour IPv6 ou au préfixe "link-local" (fe80::/10) défini dans la section 2.5.6 de la RFC4291 pour IPv6.

Un réseau public est toute autre destination.

Étant donné que l'autorisation d'accès au réseau local est limitée aux contextes sécurisés et qu'il peut être difficile de migrer les appareils du réseau local vers HTTPS, les requêtes de réseau local soumises à autorisation seront désormais exemptées des vérifications de contenu mixte si Chrome sait que les requêtes seront envoyées au réseau local avant de résoudre la destination. Chrome sait qu'une requête est envoyée au réseau local si:

• Le nom d'hôte de la requête est une adresse IP privée littérale (par exemple, 192.168.0.1).
• Le nom d'hôte de la requête est un domaine .local.
• L'appel fetch() est annoté avec l'option 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",
});

Changements dans Chrome

Chrome 138

Notre version initiale de l'accès au réseau local est prête pour les tests en option dans Chrome 138. Les utilisateurs peuvent activer la nouvelle invite d'autorisation en définissant chrome://flags#local-network-access-check sur "Activé (Blocage)". Cela permet de déclencher l'invite d'autorisation d'accès au réseau local pour les requêtes lancées à l'aide de l'API JavaScript fetch(), du chargement de sous-ressources et de la navigation dans les sous-cadres.

Un site de démonstration est disponible à l'adresse https://local-network-access-testing.glitch.me/ pour déclencher différentes formes de requêtes réseau locales.

Limites et problèmes connus

• La nouvelle invite d'autorisation n'est actuellement implémentée que dans Chrome pour ordinateur. Nous mettons tout en œuvre pour le porter sur Android Chrome. (Suivi dans crbug.com/400455013.)
• Les connexions WebSockets (crbug.com/421156866), WebTransport (crbug.com/421216834) et WebRTC (crbug.com/421223919) au réseau local ne sont pas encore limitées par l'autorisation LNA.
• Les requêtes réseau locales des services workers nécessitent actuellement que l'origine du service worker ait déjà reçu l'autorisation d'accès au réseau local.
  • Si votre application effectue des requêtes réseau locales à partir d'un service worker, vous devez actuellement déclencher séparément une requête réseau locale à partir de votre application pour déclencher l'invite d'autorisation. (Nous travaillons sur un moyen pour les travailleurs de déclencher l'invite d'autorisation si un document actif est disponible. Consultez crbug.com/404887282.)

Chrome 139 ou version ultérieure

Notre objectif est de déployer l'accès au réseau local dès que possible. Conscients que certains sites peuvent avoir besoin de plus de temps pour être mis à jour avec les annotations d'accès au réseau local, nous allons ajouter une phase d'évaluation d'abandon pour permettre aux sites de désactiver temporairement l'exigence de contextes sécurisés avant que nous ne déployions l'accès au réseau local par défaut. Cela devrait fournir un chemin de migration plus clair pour les développeurs, en particulier si vous accédez aux ressources réseau locales via HTTP (car ces requêtes seraient bloquées en tant que contenu mixte si elles sont demandées à partir d'une page HTTPS dans des navigateurs qui ne prennent pas encore en charge l'exception de contenu mixte pour l'accès au réseau local).

Nous allons également ajouter une règle Chrome d'entreprise pour contrôler les sites autorisés ou non à effectuer des requêtes réseau locales (autorisation accordée ou refusée à l'avance à ces sites). Cela permet aux installations Chrome gérées, telles que celles dans les paramètres d'entreprise, d'éviter d'afficher l'avertissement pour les cas d'utilisation prévus connus, ou de renforcer le verrouillage et d'empêcher les sites de demander l'autorisation.

Nous prévoyons de continuer à intégrer l'autorisation d'accès au réseau local à différentes fonctionnalités pouvant envoyer des requêtes au réseau local. Par exemple, nous prévoyons de lancer prochainement l'accès au réseau local pour les connexions WebSockets, WebTransport et WebRTC.

Nous vous communiquerons plus d'informations à l'approche du lancement complet de l'accès au réseau local dans Chrome.

Commentaires souhaités

Les commentaires précédents sur le développement de l'accès au réseau privé nous ont été d'une aide précieuse pour nous guider vers notre nouvelle approche d'autorisation d'accès au réseau local. Nous tenons à remercier une fois de plus toutes les personnes qui ont été impliquées au fil des ans.

Si vous développez ou utilisez un site Web qui s'appuie sur l'établissement de connexions au réseau local de l'utilisateur ou au logiciel exécuté localement sur son ordinateur, l'équipe Chrome est intéressée par vos commentaires et cas d'utilisation. Vous pouvez faire deux choses pour l'aider:

• Accédez à chrome://flags#local-network-access-check, définissez l'indicateur sur "Enabled (Blocking)" (Activé (Blocage)) et vérifiez si votre site Web déclenche correctement la nouvelle invite d'autorisation (et fonctionne comme prévu une fois l'autorisation accordée).
• Si vous rencontrez des problèmes ou si vous avez des commentaires, signalez-les dans l'outil de suivi des problèmes Chromium ou dans notre dépôt GitHub sur l'explication de la LNA. Chrome aimerait connaître votre avis.