Publié le : 9 juin 2025
Chrome ajoute une nouvelle invite d'autorisation pour les sites qui se connectent 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 autres appareils sur les réseaux privés, et de réduire la capacité des sites à utiliser ces requêtes pour identifier le 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 reposant sur l'établissement de connexions au réseau local d'un utilisateur ou à un logiciel s'exécutant localement sur la machine de l'utilisateur. À partir de Chrome 138, vous pouvez activer ces nouvelles restrictions en accédant à chrome://flags/#local-network-access-check et en définissant le flag sur "Activé (blocage)".
Qu'est-ce que l'accès au réseau local ?
L'accès au réseau local limite la capacité des sites Web à envoyer des requêtes aux serveurs du réseau local d'un utilisateur (y compris les serveurs exécutés localement sur la machine de l'utilisateur). L'utilisateur doit accorder l'autorisation au site avant que de telles 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 qu'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 lors de la configuration de nouveaux appareils Google TV et Chromecast.
Quels types de demandes sont concernés ?
Pour la première étape de l'accès au réseau local, nous considérons qu'une "requête de réseau local" est une requête envoyée depuis le réseau public vers une destination de réseau local ou de rebouclage.
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 sur une adresse IPv4 privée ou une adresse IPv6 en dehors des sous-réseaux ::1/128, 2000::/3 et ff00::/8.
Le bouclage correspond à toute destination qui se résout dans l'espace de bouclage (127.0.0.0/8) défini dans la section 3.2.1.3 de la RFC1122 d'IPv4, dans l'espace "link-local" (169.254.0.0/16) défini dans la RFC3927 d'IPv4, dans le préfixe "Unique Local Address" (fcc00::/7) défini dans la section 3 de la RFC4193 d'IPv6 ou dans le préfixe "link-local" (fe80::/10) défini dans la section 2.5.6 de la RFC4291 d'IPv6.
Pour obtenir un mappage complet des adresses IP aux espaces d'adressage, consultez le tableau dans la spécification de l'accès au réseau local.
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 avec 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 un littéral d'adresse IP privée (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'optiontargetAddressSpace: "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",
});
Modifications apportées à Chrome
Chrome 138
Notre première version de l'accès au réseau local est prête pour les tests d'activation dans Chrome 138. Les utilisateurs peuvent activer la nouvelle invite d'autorisation en définissant chrome://flags#local-network-access-check sur "Activé (bloquant)". Cela permet de déclencher l'invite d'autorisation d'accès au réseau local pour les requêtes initiées à l'aide de l'API JavaScript fetch(), du chargement de sous-ressources et de la navigation dans les sous-frames.
Un site de démonstration est disponible à l'adresse https://lna-testing.notyetsecure.com/ pour déclencher différentes formes de requêtes sur le réseau local.
Limites et problèmes connus
- Les connexions WebSockets (crbug.com/421156866), WebTransport (crbug.com/421216834) et WebRTC (crbug.com/421223919) au réseau local ne sont pas encore soumises à l'autorisation LNA.
- Les requêtes sur le réseau local provenant de Service Workers et de Shared Workers nécessitent que l'origine du worker ait déjà reçu l'autorisation d'accès au réseau local.
- Si votre application effectue des requêtes sur le réseau local à partir d'un service worker, vous devrez déclencher séparément une requête sur le réseau local à partir de votre application pour déclencher l'invite d'autorisation. (Nous travaillons sur un moyen pour les employés de déclencher l'invite d'autorisation si un document actif est disponible. Pour en savoir plus, consultez crbug.com/404887282.)
Chrome 139 et versions ultérieures
Nous prévoyons de déployer l'accès au réseau local dès que possible. Nous sommes 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 donc ajouter une phase d'évaluation de l'origine pour permettre aux sites de désactiver temporairement l'exigence de contextes sécurisés avant que nous n'activions 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 vous appuyez sur l'accès aux ressources du réseau local via HTTP (car ces requêtes seraient bloquées en tant que contenu mixte si elles étaient demandées à partir d'une page HTTPS dans les navigateurs qui ne prennent pas encore en charge l'exemption de contenu mixte pour l'accès au réseau local).
Nous ajouterons également une règle Chrome Enterprise pour contrôler les sites qui peuvent ou non effectuer des requêtes sur le réseau local (en accordant ou en refusant l'autorisation à ces sites). Cela permettra aux installations Chrome gérées, comme celles dans les environnements d'entreprise, d'éviter d'afficher l'avertissement pour les cas d'utilisation prévus connus, ou de renforcer la sécurité 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 déployer prochainement l'accès au réseau local pour les connexions WebSockets, WebTransport et WebRTC.
Nous vous fournirons plus d'informations à l'approche du lancement complet de l'accès au réseau local dans Chrome.
Nous aimerions avoir votre avis
Les commentaires précédents sur le développement de l'accès au réseau privé ont été extrêmement utiles 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 participé à ce projet au fil des ans.
Si vous développez ou utilisez un site Web qui repose sur des connexions au réseau local de l'utilisateur ou à un logiciel exécuté localement sur sa machine, l'équipe Chrome aimerait connaître vos commentaires et vos cas d'utilisation. Voici deux choses que vous pouvez faire pour l'aider :
- Accédez à
chrome://flags#local-network-access-check, définissez l'indicateur sur "Activé (blocage)", puis vérifiez si votre site Web déclenche correctement la nouvelle invite d'autorisation (et s'il fonctionne comme prévu après que vous avez accordé l'autorisation). - Si vous rencontrez des problèmes ou souhaitez nous faire part de vos commentaires, signalez-les dans l'outil de suivi des problèmes Chromium ou dans notre dépôt GitHub de la spécification LNA. Votre avis sur Chrome nous intéresse.