Explication de la permission Local Network Access (LNA) de Chrome

Vous testez une application web qui communique avec une API locale, un serveur de développement tournant sur le port 3000, ou un périphérique matériel sur votre réseau. Chrome affiche soudainement une boîte de dialogue : « [Site] souhaite rechercher et se connecter à n’importe quel appareil de votre réseau local. » Vous ne vous y attendiez pas. Voici exactement ce qui se passe et pourquoi.

Qu’est-ce que la permission Local Network Access de Chrome ?

Local Network Access (LNA) de Chrome est une modification de sécurité du navigateur qui empêche les sites web publics d’effectuer silencieusement des requêtes vers les appareils de votre réseau local. À partir de Chrome 142, le navigateur soumet ces requêtes à une demande de permission explicite de l’utilisateur.

Avant LNA, n’importe quel site web que vous visitiez pouvait utiliser votre navigateur comme proxy pour sonder discrètement votre routeur, imprimante, API locale, ou tout autre appareil sur votre réseau — sans que vous le sachiez. C’est un vecteur d’attaque réel. Un site malveillant pourrait l’exploiter pour effectuer des attaques CSRF (cross-site request forgery) contre des appareils locaux vulnérables ou cartographier la topologie de votre réseau.

LNA comble cette faille en exigeant d’abord le consentement de l’utilisateur.

Cela remplace une tentative antérieure appelée Private Network Access (PNA), qui reposait sur des preflights CORS côté serveur et nécessitait que les appareils locaux donnent explicitement leur accord. Cette approche a échoué car la mise à jour du firmware de millions de routeurs et d’appareils IoT est irréalisable. LNA transfère la responsabilité aux sites web, qui sont beaucoup plus faciles à mettre à jour.

Pour plus d’informations, consultez la mise à jour officielle de sécurité Chrome sur les restrictions Local Network Access.

Qu’est-ce qui déclenche la demande de permission Local Network Access de Chrome ?

La demande apparaît lorsqu’une page servie depuis une origine publique tente d’atteindre une destination locale ou loopback. Chrome définit trois espaces d’adressage :

Toute requête traversant de public → local ou public → loopback déclenche LNA. Scénarios de développement courants concernés :

• Une application web hébergée appelant http://192.168.1.1/api
• Un tableau de bord cloud se connectant à un agent local sur localhost:8080
• Une page de configuration d’appareil (servie depuis le site public d’un fabricant) communiquant avec du matériel sur votre réseau local
• Une solution ZTNA ou VPN routant le trafic via des plages IPv6 que Chrome classe comme locales (comme fc00::/7)

Contraintes clés que les développeurs doivent connaître

Contextes sécurisés uniquement. La permission LNA ne peut être demandée que depuis des pages HTTPS. Cependant, comme les appareils locaux ne peuvent souvent pas servir du HTTPS, Chrome peut assouplir les restrictions de contenu mixte pour les cibles clairement locales après l’octroi de la permission, car de nombreux appareils n’exposent que des endpoints HTTP.

// Chrome sait que c'est local — vérification de contenu mixte exemptée
fetch("http://192.168.0.1/ping");

// Chrome sait que c'est local via annotation
fetch("http://mydevice.example.com/ping", { targetAddressSpace: "local" });

// Chrome ne sait PAS que c'est local tant que le DNS n'est pas résolu — non exempté
fetch("http://example.com/ping");

Les workers nécessitent une gestion spéciale. Les Service Workers et Shared Workers nécessitent que l’origine parente ait déjà obtenu la permission LNA avant de pouvoir effectuer des requêtes vers le réseau local. Il n’existe aucun moyen pour un worker de déclencher directement la demande.

Les iframes nécessitent une délégation. Les frames intégrées nécessitent une délégation de permission explicite via Permissions Policy (local-network-access) pour effectuer des requêtes vers le réseau local.

WebTransport et WebRTC ne sont pas encore couverts par le contrôle LNA — la prise en charge est attendue dans les futures versions de Chrome. Les connexions WebSocket vers des adresses locales suivent les mêmes restrictions d’accès au réseau local que les autres requêtes réseau.

Pourquoi c’est plus important qu’il n’y paraît

La modification de sécurité du réseau local de Chrome aligne le navigateur sur ce qu’iOS, Android et macOS font depuis des années au niveau du système d’exploitation. Les applications sur ces plateformes demandent déjà l’accès au réseau local. Chrome rattrape son retard.

Pour les développeurs accédant à des appareils locaux depuis le navigateur — qu’il s’agisse d’un serveur de développement, d’une interface matérielle ou d’un agent local — l’impact pratique est clair : votre application doit maintenant déclencher intentionnellement la demande de permission, gérer le cas où un utilisateur la refuse, et s’assurer que les requêtes proviennent d’un contexte sécurisé.

Conclusion

La permission Local Network Access de Chrome représente un changement significatif dans la manière dont les navigateurs gèrent la frontière entre le web public et votre réseau privé. Pour les utilisateurs finaux, elle comble un angle mort de longue date. Pour les développeurs, elle introduit une nouvelle exigence : toute page d’origine publique qui accède à l’espace d’adressage local doit désormais tenir compte d’un contrôle de permission explicite.

L’ajustement est simple. Servez vos pages en HTTPS, anticipez les refus de permission dans votre interface utilisateur, déléguez l’accès aux iframes via Permissions Policy, et testez tôt. Utilisez chrome://flags/#local-network-access-check défini sur “Enabled (Blocking)” pour voir exactement ce que les utilisateurs de Chrome 142 expérimenteront. Plus tôt vous vous adapterez, moins vos utilisateurs auront de surprises.

FAQ

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.