Permiso de Acceso a Red Local (LNA) de Chrome Explicado

Estás probando una aplicación web que se comunica con una API local, un servidor de desarrollo ejecutándose en el puerto 3000, o un dispositivo de hardware en tu red. Chrome muestra repentinamente un diálogo: “[Sitio] quiere buscar y conectarse a cualquier dispositivo en tu red local.” No lo esperabas. Aquí te explicamos exactamente qué está sucediendo y por qué.

¿Qué es el Permiso de Acceso a Red Local de Chrome?

El Acceso a Red Local (LNA) de Chrome es un cambio de seguridad del navegador que previene que sitios web públicos realicen solicitudes silenciosamente a dispositivos en tu red local. A partir de Chrome 142, el navegador bloquea estas solicitudes detrás de un aviso de permiso explícito del usuario.

Antes de LNA, cualquier sitio web que visitaras podía usar tu navegador como proxy para sondear silenciosamente tu router, impresora, API local, o cualquier otro dispositivo en tu red — sin que lo supieras. Esto es un vector de ataque real. Un sitio malicioso podría explotarlo para realizar falsificación de solicitud entre sitios (CSRF) contra dispositivos locales vulnerables o crear una huella digital de la topología de tu red.

LNA cierra esa brecha al requerir primero el consentimiento del usuario.

Esto reemplaza un intento anterior llamado Acceso a Red Privada (PNA), que dependía de preflights CORS del lado del servidor y requería que los dispositivos locales optaran explícitamente por participar. Ese enfoque se estancó porque actualizar el firmware en millones de routers y dispositivos IoT es poco práctico. LNA traslada la responsabilidad a los sitios web, que son mucho más fáciles de actualizar.

Para más contexto, consulta la actualización oficial de seguridad de Chrome sobre restricciones de Acceso a Red Local.

¿Qué Desencadena el Aviso de Permiso de Acceso a Red Local de Chrome?

El aviso aparece cuando una página servida desde un origen público intenta acceder a un destino local o loopback. Chrome define tres espacios de direcciones:

Cualquier solicitud que cruce de público → local o público → loopback desencadena LNA. Escenarios comunes de desarrollo que encuentran esto:

• Una aplicación web alojada llamando a http://192.168.1.1/api
• Un panel de control en la nube conectándose a un agente ejecutándose localmente en localhost:8080
• Una página de configuración de dispositivo (servida desde el sitio público de un fabricante) comunicándose con hardware en tu LAN
• Una solución ZTNA o VPN enrutando tráfico a través de rangos IPv6 que Chrome clasifica como locales (como fc00::/7)

Restricciones Clave que los Desarrolladores Deben Conocer

Solo contextos seguros. El permiso LNA solo puede solicitarse desde páginas HTTPS. Sin embargo, dado que los dispositivos locales a menudo no pueden servir HTTPS, Chrome puede relajar las restricciones de contenido mixto para destinos claramente locales después de que se otorgue el permiso, ya que muchos dispositivos solo exponen endpoints HTTP.

// Chrome sabe que esto es local — verificación de contenido mixto exenta
fetch("http://192.168.0.1/ping");

// Chrome sabe que esto es local mediante anotación
fetch("http://mydevice.example.com/ping", { targetAddressSpace: "local" });

// Chrome NO sabe que esto es local hasta que DNS resuelva — no exento
fetch("http://example.com/ping");

Los Workers necesitan manejo especial. Los Service Workers y Shared Workers requieren que el origen padre ya haya recibido el permiso LNA antes de que puedan realizar solicitudes a la red local. No hay forma de que un worker desencadene el aviso directamente.

Los Iframes requieren delegación. Los frames embebidos necesitan delegación explícita de permisos mediante Permissions Policy (local-network-access) para realizar solicitudes a la red local.

WebTransport y WebRTC aún no están cubiertos por el bloqueo LNA — se espera soporte en futuras versiones de Chrome. Las conexiones WebSocket a direcciones locales siguen las mismas restricciones de acceso a red local que otras solicitudes de red.

Por Qué Esto Importa Más de lo que Parece

El cambio de seguridad de red local de Chrome alinea al navegador con lo que iOS, Android y macOS han hecho durante años a nivel del sistema operativo. Las aplicaciones en esas plataformas ya solicitan acceso a la red local. Chrome se está poniendo al día.

Para los desarrolladores que acceden a dispositivos locales desde el navegador — ya sea un servidor de desarrollo, una interfaz de hardware, o un agente local — el impacto práctico es claro: tu aplicación ahora necesita desencadenar el aviso de permiso intencionalmente, manejar el caso donde un usuario lo deniegue, y asegurar que las solicitudes se originen desde un contexto seguro.

Conclusión

El permiso de Acceso a Red Local de Chrome es un cambio significativo en cómo los navegadores manejan la frontera entre la web pública y tu red privada. Para los usuarios finales, cierra un punto ciego de larga data. Para los desarrolladores, introduce un nuevo requisito: cualquier página de origen público que acceda al espacio de direcciones local ahora debe tener en cuenta una barrera de permiso explícita.

El ajuste es sencillo. Sirve tus páginas a través de HTTPS, anticipa las denegaciones de permisos en tu interfaz de usuario, delega acceso a iframes mediante Permissions Policy, y prueba temprano. Usa chrome://flags/#local-network-access-check configurado en “Enabled (Blocking)” para ver exactamente lo que experimentarán los usuarios de Chrome 142. Cuanto antes te adaptes, menos sorpresas enfrentarán tus usuarios.

Preguntas Frecuentes

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.