Esta página foi traduzida pela API Cloud Translation.

Novo aviso de permissão para o acesso à rede local

Chris Thompson

Publicado em 9 de junho de 2025

O Chrome está adicionando uma nova solicitação de permissão para sites que fazem conexões com a rede local de um usuário como parte da especificação de acesso à rede local. O objetivo é proteger os usuários contra ataques de falsificação de solicitações entre sites (CSRF, na sigla em inglês) para roteadores e outros dispositivos em redes privadas, além de reduzir a capacidade dos sites de usar essas solicitações para criar uma impressão digital da rede local do usuário.

Para entender como essa mudança afeta o ecossistema da Web, a equipe do Chrome está buscando feedback de desenvolvedores que criam aplicativos da Web que dependem de conexões com a rede local de um usuário ou com softwares executados localmente no computador dele. A partir do Chrome 138, você pode ativar essas novas restrições acessando chrome://flags/#local-network-access-check e definindo a flag como "Ativado (bloqueio)".

O que é o acesso à rede local?

O acesso à rede local restringe a capacidade dos sites de enviar solicitações a servidores em uma rede local do usuário (incluindo servidores executados localmente na máquina do usuário), exigindo que o usuário conceda permissão ao site antes que essas solicitações possam ser feitas. A capacidade de solicitar essa permissão é restrita a contextos seguros.

Uma solicitação com o texto "Buscar e se conectar a qualquer dispositivo na sua rede local". — Exemplo da solicitação de permissão de acesso à rede local do Chrome.

Muitas outras plataformas, como Android, iOS e MacOS têm uma permissão de acesso à rede local. Por exemplo, você pode ter concedido essa permissão para acessar a rede local ao app Google Home ao configurar novos dispositivos Google TV e Chromecast.

Quais tipos de solicitações são afetados?

Para a primeira etapa do acesso à rede local, consideramos uma "solicitação de rede local" como qualquer solicitação da rede pública para uma rede local ou um destino de loopback.

Uma rede local é qualquer destino que seja resolvido para o espaço de endereços privados definido na Seção 3 da RFC1918 em IPv4 (por exemplo, 192.168.0.0/16), um endereço IPv6 mapeado para IPv4 em que o endereço IPv4 mapeado é privado ou um endereço IPv6 fora das sub-redes ::1/128, 2000::/3 e ff00::/8.

Loopback é qualquer destino que seja resolvido para o espaço "loopback" (127.0.0.0/8) definido na seção 3.2.1.3 da RFC1122 do IPv4, o espaço "link-local" (169.254.0.0/16) definido na RFC3927 do IPv4, o prefixo "Unique Local Address" (fcc00::/7) definido na seção 3 da RFC4193 do IPv6 ou o prefixo "link-local" (fe80::/10) definido na seção 2.5.6 da RFC4291 do IPv6.

Para um mapeamento completo de endereços IP para espaços de endereços, consulte a tabela na especificação de acesso à rede local.

Uma rede pública é qualquer outro destino.

Como a permissão de acesso à rede local é restrita a contextos seguros e pode ser difícil migrar dispositivos de rede local para HTTPS, as solicitações de rede local protegidas por permissão agora serão isentas de verificações de conteúdo misto se o Chrome souber que as solicitações serão enviadas para a rede local antes de resolver o destino. O Chrome sabe que uma solicitação está indo para a rede local se:

O nome do host da solicitação é um literal de IP particular (por exemplo, 192.168.0.1).
O nome do host da solicitação é um domínio .local.
A chamada fetch() é anotada com a opção 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",
});

O que está mudando no Chrome

Chrome 138

Nossa versão inicial do acesso à rede local está pronta para testes de ativação no Chrome 138. Os usuários podem ativar o novo aviso de permissão definindo chrome://flags#local-network-access-check como "Ativado (bloqueio)". Isso permite acionar a solicitação de permissão de acesso à rede local para solicitações iniciadas usando a API JavaScript fetch(), carregamento de subrecursos e navegação de subframes.

Um site de demonstração está disponível em https://lna-testing.notyetsecure.com/ para acionar diferentes formas de solicitações de rede local.

Limitações e problemas conhecidos

As conexões WebSockets (crbug.com/421156866), WebTransport (crbug.com/421216834) e WebRTC (crbug.com/421223919) com a rede local ainda não são controladas pela permissão LNA.
As solicitações de rede local de Service Workers e Shared Workers exigem que a origem do worker tenha recebido anteriormente a permissão de acesso à rede local.
- Se o aplicativo fizer solicitações de rede local de um service worker, será necessário acionar separadamente uma solicitação de rede local do aplicativo para acionar a solicitação de permissão. Estamos trabalhando em uma maneira de os trabalhadores acionarem a solicitação de permissão se houver um documento ativo disponível. Consulte crbug.com/404887282.

Chrome 139 e versões mais recentes

Nossa intenção é lançar o acesso à rede local assim que possível. Sabemos que alguns sites podem precisar de mais tempo para serem atualizados com anotações de acesso à rede local. Por isso, vamos adicionar um teste de origem para permitir que os sites desativem temporariamente o requisito de contextos seguros antes de lançarmos o acesso à rede local por padrão. Isso deve fornecer um caminho de migração mais claro para os desenvolvedores, especialmente se você depender do acesso a recursos de rede local por HTTP. Essas solicitações seriam bloqueadas como conteúdo misto se fossem feitas de uma página HTTPS em navegadores que ainda não oferecem suporte à exceção de conteúdo misto de acesso à rede local.

Também vamos adicionar uma política empresarial do Chrome para controlar quais sites podem e não podem fazer solicitações de rede local (concedendo ou negando previamente a permissão a esses sites). Isso permite que instalações gerenciadas do Chrome, como as em ambientes corporativos, evitem mostrar o aviso para casos de uso conhecidos, ou restrinjam ainda mais e impeçam que os sites solicitem a permissão.

Planejamos continuar integrando a permissão de acesso à rede local com diferentes recursos que podem enviar solicitações à rede local. Por exemplo, planejamos lançar o acesso à rede local para conexões WebSockets, WebTransport e WebRTC em breve.

Vamos compartilhar mais informações à medida que nos aproximarmos do lançamento completo do acesso à rede local no Chrome.

Queremos seu feedback

O feedback anterior sobre o desenvolvimento do acesso à rede privada foi muito valioso para nos guiar até nossa nova abordagem de permissão de acesso à rede local. Agradecemos mais uma vez a todos que participaram ao longo dos anos.

Se você desenvolve ou usa um site que depende de conexões com a rede local do usuário ou um software executado localmente no computador dele, a equipe do Chrome quer saber sua opinião e seus casos de uso. Há duas coisas que você pode fazer para ajudar:

Acesse chrome://flags#local-network-access-check, defina a flag como "Ativado (bloqueio)" e verifique se o site aciona corretamente a nova solicitação de permissão e funciona como esperado depois que você concede a permissão.
Se você encontrar problemas ou tiver feedback, registre um problema no Issue Tracker do Chromium ou no repositório do GitHub da especificação LNA. O Chrome quer saber sua opinião.