Permissão de Acesso à Rede Local (LNA) do Chrome Explicada

Você está testando uma aplicação web que se comunica com uma API local, um servidor de desenvolvimento rodando na porta 3000, ou um dispositivo de hardware na sua rede. De repente, o Chrome exibe uma caixa de diálogo: “[Site] quer procurar e conectar-se a qualquer dispositivo na sua rede local.” Você não estava esperando por isso. Aqui está exatamente o que está acontecendo e por quê.

O Que É a Permissão de Acesso à Rede Local do Chrome?

O Acesso à Rede Local (LNA) do Chrome é uma mudança de segurança do navegador que impede sites públicos de fazerem requisições silenciosamente a dispositivos na sua rede local. A partir do Chrome 142, o navegador controla essas requisições através de uma solicitação de permissão explícita ao usuário.

Antes do LNA, qualquer site que você visitasse poderia usar seu navegador como proxy para sondar silenciosamente seu roteador, impressora, API local ou qualquer outro dispositivo na sua rede — sem você saber. Isso é um vetor de ataque real. Um site malicioso poderia explorar isso para realizar falsificação de requisição entre sites (CSRF) contra dispositivos locais vulneráveis ou mapear a topologia da sua rede.

O LNA fecha essa brecha exigindo primeiro o consentimento do usuário.

Isso substitui uma tentativa anterior chamada Acesso à Rede Privada (PNA), que dependia de preflights CORS no lado do servidor e exigia que dispositivos locais optassem explicitamente. Essa abordagem estagnou porque atualizar firmware em milhões de roteadores e dispositivos IoT é impraticável. O LNA transfere a responsabilidade para os sites, que são muito mais fáceis de atualizar.

Para mais contexto, veja a atualização oficial de segurança do Chrome sobre restrições de Acesso à Rede Local.

O Que Aciona a Solicitação de Permissão de Acesso à Rede Local do Chrome?

A solicitação aparece quando uma página servida de uma origem pública tenta alcançar um destino local ou loopback. O Chrome define três espaços de endereço:

Qualquer requisição cruzando de público → local ou público → loopback aciona o LNA. Cenários comuns de desenvolvimento que encontram isso:

• Uma aplicação web hospedada chamando http://192.168.1.1/api
• Um painel em nuvem conectando-se a um agente rodando localmente em localhost:8080
• Uma página de configuração de dispositivo (servida do site público do fabricante) comunicando-se com hardware na sua LAN
• Uma solução ZTNA ou VPN roteando tráfego através de faixas IPv6 que o Chrome classifica como locais (como fc00::/7)

Restrições Principais Que Desenvolvedores Precisam Conhecer

Apenas contextos seguros. A permissão LNA só pode ser solicitada de páginas HTTPS. No entanto, como dispositivos locais frequentemente não podem servir HTTPS, o Chrome pode relaxar restrições de conteúdo misto para alvos claramente locais após a permissão ser concedida, já que muitos dispositivos expõem apenas endpoints HTTP.

// Chrome sabe que isso é local — verificação de conteúdo misto isenta
fetch("http://192.168.0.1/ping");

// Chrome sabe que isso é local via anotação
fetch("http://mydevice.example.com/ping", { targetAddressSpace: "local" });

// Chrome NÃO sabe que isso é local até o DNS resolver — não isento
fetch("http://example.com/ping");

Workers precisam de tratamento especial. Service Workers e Shared Workers exigem que a origem pai já tenha recebido a permissão LNA antes de poderem fazer requisições à rede local. Não há como um worker acionar a solicitação diretamente.

Iframes exigem delegação. Frames incorporados precisam de delegação explícita de permissão via Permissions Policy (local-network-access) para fazer requisições à rede local.

WebTransport e WebRTC ainda não são cobertos pelo controle LNA — o suporte é esperado em versões futuras do Chrome. Conexões WebSocket para endereços locais seguem as mesmas restrições de acesso à rede local que outras requisições de rede.

Por Que Isso Importa Mais Do Que Parece

A mudança de segurança de rede local do Chrome alinha o navegador com o que iOS, Android e macOS têm feito há anos no nível do sistema operacional. Aplicativos nessas plataformas já solicitam acesso à rede local. O Chrome está se atualizando.

Para desenvolvedores acessando dispositivos locais do navegador — seja um servidor de desenvolvimento, uma interface de hardware ou um agente local — o impacto prático é claro: sua aplicação agora precisa acionar a solicitação de permissão intencionalmente, lidar com o caso em que um usuário a nega e garantir que as requisições se originem de um contexto seguro.

Conclusão

A permissão de Acesso à Rede Local do Chrome é uma mudança significativa em como os navegadores lidam com a fronteira entre a web pública e sua rede privada. Para usuários finais, fecha um ponto cego de longa data. Para desenvolvedores, introduz um novo requisito: qualquer página de origem pública que alcance o espaço de endereço local deve agora considerar um controle de permissão explícito.

O ajuste é direto. Sirva suas páginas via HTTPS, antecipe negações de permissão na sua interface, delegue acesso a iframes via Permissions Policy e teste cedo. Use chrome://flags/#local-network-access-check configurado para “Enabled (Blocking)” para ver exatamente o que os usuários do Chrome 142 experimentarão. Quanto mais cedo você se adaptar, menos surpresas seus usuários enfrentarão.

Perguntas Frequentes

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.