Adaptar seu site para novas restrições de Acesso à Rede Local no Microsoft Edge

Última atualização: 9 de março de 2026

As restrições de Acesso à Rede Local começarão a ser enviadas por padrão no Microsoft Edge 143. Para obter mais informações sobre o que é Acesso à Rede Local e as motivações para exigir permissão do usuário para fazer solicitações de rede local, consulte a especificação de Acesso à Rede Local.

Se você tiver um site que precisa se conectar a um servidor que executa o localhost ou em algum lugar na rede local do usuário (possivelmente por meio de uma biblioteca de terceiros), este documento tenta responder a perguntas comuns e fornecer orientações sobre como adaptar seu site para trabalhar com essas novas restrições.

Em muitos casos, as solicitações de rede local devem continuar funcionando como antes, mas os usuários veem uma solicitação de permissão na primeira vez que ocorrem em um site. Em alguns casos, você precisa ajustar seu site para que essas solicitações continuem funcionando (e não sejam bloqueadas como conteúdo misto). Por exemplo, se você fizer solicitações fetch() para um nome de domínio público, que resolve para um endereço de rede local, você precisa marcar explicitamente suas chamadas fetch() como indo para um endereço local. Ou, se hoje você precisa hospedar seu site em HTTP (em vez de HTTPS) devido ao bloqueio de conteúdo misto, você deseja se inscrever em nosso Origin Trial para isentar temporariamente seu site dos requisitos de HTTPS para solicitar a permissão do LNA.

Qual é o escopo atual das restrições do LNA no Microsoft Edge?

A solicitação de permissão é disparada quando uma conexão é feita com um destino na rede local ou no host local. A partir do Microsoft Edge 143, as restrições do LNA se aplicam a:

  • Solicitações de sub-recursos
  • solicitações fetch()
  • Navegando por subquadros

As restrições do LNA não se aplicarão inicialmente aos seguintes tipos de conexão, embora planejemos incluí-las em breve:

  • WebSockets
  • WebTransport
  • WebRTC

No momento, não temos planos de aplicar restrições do LNA à navegação do quadro principal. (Embora um bug em nossa implementação de rascunho no Edge 139 e anteriores tenha impactado acidentalmente a navegação do quadro principal.)

No momento, não temos planos de aplicar restrições do LNA a extensões. Atualmente, as extensões que têm as permissões de host necessárias têm permissão para fazer solicitações de rede local.

As restrições do LNA não se aplicam ao Android WebView. Os aplicativos Android que incorporam WebViews que fazem solicitações de rede local estão sujeitos à nova permissão de rede local do Android.

Como fornecer aos meus usuários contexto adicional para a solicitação de permissão do LNA?

Ao solicitar uma permissão, pode ser útil fornecer ao usuário algum contexto adicional em seu aplicativo Web sobre por que você precisa da permissão e para que usá-la. A API de permissões permite que você consulte se um usuário concedeu (ou negou) uma determinada permissão e, assim, personalize sua interface do usuário de acordo.

Devido à forma como a API de permissões funciona, consultar o estado da permissão de acesso à rede local retorna "prompt" independentemente de o sinalizador de recurso LNA estar habilitado, se o usuário não tiver a permissão concedida ou negada. O sinalizador de recurso está habilitado por padrão no Microsoft Edge 143, para que você possa despachar comportamentos diferentes com base na versão principal na cadeia de caracteres do agente do usuário.

Para fornecer mais contexto antes de disparar a solicitação de permissão do LNA, nossa orientação atual é usar um padrão como o seguinte:

  • Se o cliente for < Edge 143, as solicitações de rede local deverão funcionar silenciosamente
  • Se o cliente for Edge >= 143, consulte a API de permissões (consulte o exemplo de chamada abaixo)
    • Se a permissão for concedida, prossiga com a tentativa de solicitação
    • Se a permissão for negada, opcionalmente, mostre a interface do usuário para ajudar o usuário a corrigir, se necessário
    • Se o status da permissão for "prompt", contextualize em seu aplicativo que um prompt ocorre

Exemplo de chamada à API de permissões:

navigator.permissions.query({ name: "local-network-access" })
.then((result) => {
  console.log(`LNA permission state: ${result.state}`)
});

Observação: a API de permissões sempre retornará "negado" quando chamado de uma página HTTP.

Como posso disparar programaticamente a solicitação de permissão?

A solicitação de permissão do LNA não será disparada se uma conexão não for estabelecida com o ponto de extremidade remoto. Se for mais fácil para o seu fluxo de trabalho acionar a solicitação de permissão antes de tentar estabelecer uma conexão com o dispositivo local, uma maneira de contornar isso é fazer uma solicitação fetch() para um nome de host que possa ser verificado para estar nos espaços de endereço local ou de loopback por exame visual do nome do host (ou seja, localhost ou um loopback ou literal de endereço IP local).

Na prática, isso significa que, se você estiver disparando uma solicitação de permissão para conexões com o host local, no JavaScript, acione uma chamada fetch() da seguinte maneira:

fetch("http://localhost")

Ou, se você estiver disparando uma solicitação de permissão para uma conexão com um dispositivo local:

fetch("https://10.0.0.1")

Algumas notas:

  • Funciona no Microsoft Edge 144 ou superior
  • Se o usuário aceitou (ou negou) a permissão, o usuário não verá outra solicitação de permissão.
  • Isso não acionará uma solicitação de permissão se o contexto no qual o fetch() foi executado não precisar de permissão para entrar em contato com o localhost (ou a rede local)

Como posso fazer solicitações de rede local de dentro de um iframe?

Fazer uma solicitação de rede local de dentro de um iframe requer que o documento incorporado especifique o sinalizador da política de permissões de acesso à rede local no iframe. Por exemplo, se domainA.example incluir um iframe para domainB.example, você precisará delegar explicitamente a permissão ao iframe da seguinte maneira:

<iframe src="domainB.example" allow="local-network-access"></iframe>

Quando uma solicitação de rede local é feita a partir do documento incorporado, ela é tratada como se o documento incorporado tivesse solicitado a permissão LNA, e qualquer decisão de permissão do usuário será vinculada à origem do documento incorporado.

Se o documento dentro do iframe navegar para outros documentos que também fazem solicitações de rede local, você deverá especificar todas as origens de todos os documentos que podem fazer solicitações de rede local no sinalizador da política de permissão. Para estender o exemplo acima, se domainB.example navegar do iframe para domainC.example e domainB.example e domainC.example fizerem uma solicitação de acesso à rede local, você precisará delegar explicitamente a permissão para ambas as origens da seguinte maneira:

<iframe src="domainB.example" allow="local-network-access domainB.example domainC.example"></iframe>

Você também pode especificar allow="local-network-access *" para permitir que todas as origens que podem ser carregadas no iframe façam solicitações de rede local (mesmo que você não saiba necessariamente o que elas estão com antecedência). Por exemplo, isso pode ser útil nos casos em que um iframe pode fazer redirecionamentos arbitrários para outra origem (como para SSO) antes de redirecionar de volta para o host local.

Outras coisas a serem observadas:

  • A página de inserção e o iframe devem ser contextos seguros para solicitar a permissão do LNA.
  • Solicitar a permissão do LNA de dentro de um iframe aninhado (por exemplo, domainA.example incorpora um iframe para domainB.example, que incorpora um iframe para domainC.example, que faz a solicitação de rede local) requer que todos os iframes especifiquem o sinalizador da política de permissões de acesso à rede local.
  • A política de permissão deve ser definida em iframes que fazem solicitações de rede local, mesmo se você estiver ignorando a solicitação de permissão por meio da política corporativa.

Como posso fazer solicitações de rede local de um Trabalho de Serviço ou Trabalhador Compartilhado?

Há suporte para solicitações de rede local de Trabalhadores de Serviço e Trabalhadores Compartilhados, desde que a origem do trabalhador já tenha recebido a permissão LNA em um contexto de janela principal. Você deseja tentar solicitar a permissão fazendo uma solicitação inicial de rede local na janela principal do aplicativo e, em seguida, seus funcionários podem usar essa permissão (inclusive em segundo plano).

Como posso fazer solicitações de rede local de um trabalhador dedicado?

Os Trabalhos Dedicados são estritamente de propriedade de uma janela principal existente, portanto, as solicitações de rede local de um Trabalhador Dedicado disparam a solicitação de permissão do LNA na janela de propriedade.

Como posso evitar que minhas solicitações de rede local sejam bloqueadas como conteúdo misto?

Com o LNA, determinadas solicitações de rede local agora estão isentas do bloqueio de conteúdo misto, permitindo que sites HTTPS façam solicitações de rede local para estes pontos de extremidade HTTP:

  • Domínios locais (por exemplo, http://printer.local)
  • Literais de IP privado (por exemplo, http://192.168.0.1/)

Além disso, ao usar a API fetch(), você pode especificar a opção targetAddressSpace para marcar que uma solicitação é destinada à rede local ou ao endereço de loopback. Por exemplo:

  • fetch('http://domainA.example', {targetAddressSpace: 'local'}) funciona se domainA.example resolve para um endereço IP local como 192.168.10.1
  • fetch('http://domainB.example', {targetAddressSpace: 'loopback'}) funcionará se domainB.example resolver para o endereço de loopback 127.0.0.1

Todos eles serão isentos do bloqueio de conteúdo misto.

Como posso fazer solicitações de rede local a partir de uma página HTTP?

Para solicitar a permissão do LNA, um site servido por HTTPS (ou seja, o LNA requer um contexto seguro). No entanto, devido às complexidades de fazer solicitações de rede local, em que às vezes os destinos atualmente não dão suporte a HTTPS confiável publicamente, isso significa que essas solicitações de rede local HTTP podem ser bloqueadas como conteúdo misto.

Embora o LNA tente criar exceções para os casos comuns (consulte a seção acima sobre "Como posso evitar que minhas solicitações de rede local sejam bloqueadas como conteúdo misto?"), pode ser que não seja simples adaptar seu site para evitar problemas com conteúdo misto.

Se você precisar de mais tempo para mudar seu site para usar HTTPS ou encontrar problemas de bloqueio com as exceções de conteúdo misto do LNA conforme elas estão implementadas atualmente no Microsoft Edge, inscreva-se para uma avaliação de origem para permitir temporariamente que seu site HTTP solicite a permissão do LNA.

Observação: O token de teste de origem deve ser servido por meio de cabeçalhos HTTP. Este teste de origem não dá suporte a tokens entregues por meio de metatags ou programaticamente via JS.

Qual a melhor forma de manter a compatibilidade entre navegadores?

Como navegadores diferentes estão implantando essas restrições em momentos diferentes, talvez seja necessário implementar alguma lógica de detecção de agente do usuário para maximizar a compatibilidade.

A principal diferença de compatibilidade entre um navegador que oferece suporte à nova especificação de Acesso à Rede Local e um que ainda não oferece é em relação ao conteúdo misto. Em navegadores que dão suporte a LNA, o acesso à rede local e a permissão LNA só estão disponíveis em origens seguras. As solicitações de origens inseguras falham.

Em navegadores que ainda não dão suporte à especificação LNA, é provável que a maior parte do acesso à rede local tenha sido realizada de uma origem insegura para evitar que solicitações inseguras a recursos locais fossem identificadas como conteúdo misto.

Se, no momento, você veicula sua página por HTTP devido a esse bloqueio de conteúdo misto, convém veicular um redirecionamento para HTTPS para o Microsoft Edge 143 e superior, mas continuar atendendo a outros navegadores por HTTP (até que eles também enviem as restrições do LNA e as exceções de conteúdo misto).

Se você fizer solicitações de rede local apenas para localhost, já deverá ser capaz de servir seu site por HTTPS, pois localhost é considerado uma origem segura pela especificação de conteúdo misto e não será bloqueado como conteúdo misto.

Durante a distribuição do Microsoft Edge, você pode se inscrever em uma avaliação de origem para habilitar temporariamente a solicitação de permissão do LNA em suas origens inseguras (HTTP). Saiba mais sobre como se inscrever nas avaliações de origem. Essa avaliação de origem só estará disponível por meio do Microsoft Edge 146 (que está agendado para ir para o canal Estável em março de 2026). Os usuários da avaliação de origem devem tentar migrar para HTTPS antes desse período.

Como posso testar a permissão do LNA no EdgeDriver/Selenium/etc.?

A permissão de acesso à rede local pode ser gerenciada por meio do WebDriver/EdgeDriver. Consulte a documentação do Selenium sobre a funcionalidade específica do Edge e a documentação do Microsoft Edge sobre como usar o WebDriver para automatizar o Microsoft Edge. Para gerenciar permissões especificamente, consulte o comando setPermissions WebDriver e a especificação de protocolo.

Como posso disparar o prompt do LNA em meus testes locais?

Como as restrições do LNA ainda não se aplicam a solicitações → loopback local ou local→, as configurações típicas de desenvolvimento local (como executar um servidor no localhost) não dispararão a solicitação de permissão no Microsoft Edge.

No entanto, pode ser útil que a solicitação de permissão seja acionada em testes locais, por exemplo, se você estiver trabalhando na personalização da interface do usuário para adicionar mais contexto antes da solicitação ou para ajudar os usuários a se recuperarem caso tenham negado a permissão (consulte Como posso fornecer aos meus usuários mais contexto para a solicitação de permissão do LNA? Acima).

O Microsoft Edge fornece duas maneiras de fazer com que uma página seja tratada como se tivesse sido servida de um endereço público:

  • O cabeçalho Content-Security-Policy: treat-as-public-address no documento HTML faz com que esse documento seja tratado como se fosse servido de um endereço público.
  • O sinalizador de linha de comando --ip-address-space-overrides pode ser usado para forçar que endereços IP específicos sejam tratados como um espaço de endereço específico (público, local ou loopback).

Exemplo de sinalizador de substituição de espaço de endereço: Seu servidor de desenvolvimento local principal é executado em 192.168.10.11, que faz solicitações para um servidor separado em execução em 192.168.10.12. Você pode passar --ip-address-space-overrides=192.168.10.11:0=public ao executar o Microsoft Edge para forçar 192.168.10.11 a ser tratado como um endereço público (uma porta de 0 significa "aplicar a todas" portas"). Em seguida, quando as solicitações forem feitas ao servidor em execução em 192.168.10.12, elas serão tratadas como solicitações de rede local e dispararão a solicitação de permissão.

Como posso evitar disparar o prompt LNA em meus testes automatizados?

As restrições do LNA ainda não se aplicam a solicitações → loopback local ou local→, mas algumas configurações de teste baseadas em navegador podem envolver servidores locais que podem fazer com que o prompt do LNA seja acionado. Se isso for inesperado e não corresponder à jornada real do usuário que você está testando (por exemplo, seu site de produção só faria solicitações aos serviços públicos), você poderá configurar o Microsoft Edge para tratar endereços IP específicos como públicos usando o sinalizador de linha de comando --ip-address-space-overrides=ip-address>:<port>=<address-space e, portanto, as solicitações a eles de sites públicos não dispararão o prompt do LNA.

Você pode especificar uma porta de 0 para aplicar a substituição a todas as portas nesse endereço IP. Você pode especificar várias regras de substituição, separadas por vírgula (por exemplo, ip-address-space-overrides=192.168.0.1:8080=public,10.0.1.20:0=loopback). Você pode encontrar a gramática completa da bandeira aqui.

Exemplo: seu servidor de preparo é executado em 23.220.75.232 (um endereço IP público), mas faz solicitações para um serviço executado internamente em 10.0.1.108 (um endereço IP privado). Na produção, esse serviço é executado em um endereço IP público, portanto, não se espera que usuários reais vejam o prompt do LNA. No equipamento de teste automatizado para esse serviço, você passa o sinalizador de linha de comando --ip-address-space-overrides=10.0.1.108:0=public para que todas as conexões com esse endereço IP sejam consideradas públicas e nenhum prompt do LNA seja acionado no teste.

Como determinar por que um site está bloqueado pelo LNA

Sempre que uma aplicação web tenta acessar recursos considerados como estando na rede local, um prompt é acionado para permitir que o usuário permita ou bloqueie tal solicitação:

testingnotsecure

Permitir o acesso geralmente desbloqueia a funcionalidade que o aplicativo Web espera. Atualmente, quando a tentativa de acesso à rede local está indo para (ou vindo de) um iframe de origem cruzada considerado como estando na rede local, isentar o aplicativo Web (manualmente ou por meio da política de grupo) não funcionará.

Esse cenário de iframe geralmente é acompanhado por um erro de console do DevTools:

Access to fetch at 'http://127.0.0.1:8080/data' from origin 'https://example.com'  

has been blocked by CORS policy: Permission was denied for this request to access the `unknown` address space.

Identificando os hosts de origem cruzada e de nível superior definidos para o iframe. Embora seja recomendável adaptar um aplicativo Web afetado para adicionar a permissão 'local-network-access' no iframe, isso pode não ser possível sem controle direto sobre o código do aplicativo Web.

Certas bibliotecas usadas em aplicativos da web que podem ser usadas em iframes entre origens já lançaram correções para dar suporte às permissões LNA necessárias, como MSAL-browser, incluídas na versão 4.26.1 ou superior.

Como atenuar o impacto de iframes entre origens

Quando os hosts de nível superior ou iframe são considerados como estando na rede local, dependendo das condições específicas da rede, a única maneira de reduzir o impacto sem realizar alterações de código é usar a configuração de LocalNetworkAccessRestrictionsTemporaryOptOut política.

Com o Microsoft Edge 146 Estável, as seguintes políticas adicionais estão disponíveis para atenuar cenários em que as restrições de Acesso à Rede Local afetam iframes entre origens:

A política LocalNetworkAccessIpAddressSpaceOverrides também pode ser usada para tratar o intervalo de endereços NAT (CGN) de nível de operadora como público quando exigido por determinadas configurações de rede. Por exemplo, para isentar o intervalo de endereços CGN, configure a política com o valor:

100.64.0.0/10=public

Diretrizes de política para cenários comuns de Acesso à Rede Local

Em geral, as configurações de política a seguir devem ser usadas dependendo do cenário que está causando a restrição de Acesso à Rede Local.

  1. Cenários de endereço IP CGN

    Se o problema for causado por um endereço IP CGN (Carrier-grade NAT) sendo classificado como local, o uso da política LocalNetworkAccessIpAddressSpaceOverrides para reclassificar o intervalo de endereços CGN como público deve ser suficiente.

  2. Cenários de endereço IP local

    Se o problema for causado por um endereço IP local real, o uso da política LocalNetworkAccessAllowedForUrls para isentar o domínio primário poderá resolver o problema se:

    • O site não contém iframes entre origens.
    • O site contém iframes entre origens que incluem a permissão de local-network-access iframe no código do site.

  3. Cenários de iframe entre origens sem a permissão necessária

    Se o iframe entre origens não incluir a permissão de local-network-access iframe, o problema só poderá ser resolvido por:

Diretrizes de teste para ambientes corporativos

Para acomodar essas configurações de política em seu ambiente, defina um plano de teste antes da implantação ampla. As etapas a seguir podem ser usadas como uma linha de base geral:

  • Valide quais hosts resolvem para o intervalo de endereços CGN e identifique os sites onde eles são usados.

  • Se a política LocalNetworkAccessAllowedForUrls estiver configurada, remova temporariamente todas as entradas dela (exceto as entradas necessárias para o SharePoint ou o OneDrive). Em seguida, use a política LocalNetworkAccessIpAddressSpaceOverrides para reclassificar o espaço de endereço CGN como público, se aplicável.

  • Teste os sites afetados e, se um prompt de acesso à rede local for exibido, o host de nível superior pode precisar ser permitido com a política LocalNetworkAccessAllowedForUrls .

  • Para sites em que o problema persiste (ou seja, o prompt do LNA foi permitido, mas o site ainda falha, a menos que a política de recusa seja usada), considere habilitar a política LocalNetworkAccessPermissionsPolicyDefaultEnabled junto com LocalNetworkAccessAllowedForUrls .

  • Teste essas configurações com um grupo representativo de usuários de diferentes departamentos que dependem de diferentes aplicativos Web e ajuste a configuração de política conforme necessário.

Como posso fornecer comentários sobre o LNA em geral?

Registre um problema com seus comentários no repositório de especificações de Acesso à Rede Local no GitHub.

Como posso relatar bugs na implementação do LNA do Microsoft Edge?

Para problemas específicos da implementação do Acesso à Rede Local pelo Microsoft Edge, use os canais de comentários do Microsoft Edge ou entre em contato com o Suporte da Microsoft para clientes corporativos.

[Enterprise] Como colocar URLs na lista de permissões ou de bloqueios para solicitações de rede local

Há duas políticas corporativas para o LNA: LocalNetworkAccessAllowedForUrls e LocalNetworkAccessBlockedForUrls. Elas podem ser usadas para permitir solicitações de rede local de uma URL sem mostrar o prompt de permissão ou para impedir que uma URL faça solicitações de rede local.

Essas políticas também dão suporte a curingas com sintaxe de Padrão de URL .

A política LocalNetworkAccessAllowedForUrls se aplica à origem de nível superior do site que faz a solicitação. Se o acesso real à rede local estiver sendo feito dentro de um iframe inserido nessa página (ou em um iframe aninhado), todos os iframes devem definir o sinalizador da política de permissões.

[Enterprise] Configurei LocalNetworkAccessAllowedForUrls, mas ainda estou tendo problemas

Se você definiu a política LocalNetworkAccessAllowedForUrls corretamente, mas seus aplicativos ainda não estão funcionando, é provável que você precise corrigir seus iframes. Consulte a seção acima intitulada "Como posso fazer solicitações de rede local de dentro de um iframe?"

Há também uma política corporativa temporária, LocalNetworkAccessRestrictionsTemporaryOptOut, que permite que as empresas recusem todas as restrições do LNA. Essa política é temporária e será removida após o Edge 152.

Observação: essas políticas podem ser configuradas usando a Política de Grupo (por meio de modelos ADMX), o Microsoft Intune (usando o Catálogo de Configurações) ou outras soluções de Gerenciamento de Dispositivos Móveis (MDM). Para obter mais informações sobre como configurar políticas do Microsoft Edge, consulte Configurar configurações de política do Microsoft Edge.

  • Last updated on