Nuevo mensaje de permiso para el acceso a la red local

Chris Thompson
Chris Thompson

Fecha de publicación: 9 de junio de 2025

Chrome agregará un nuevo mensaje de permiso para los sitios que establezcan conexiones con la red local de un usuario como parte del borrador de la especificación de Acceso a la Red Local. El objetivo es proteger a los usuarios de los ataques de falsificación de solicitudes entre sitios (CSRF) dirigidos a routers y otros dispositivos en redes privadas, y reducir la capacidad de los sitios para usar estas solicitudes para crear huellas digitales de la red local del usuario.

Para comprender cómo este cambio afecta al ecosistema web, el equipo de Chrome está buscando comentarios de los desarrolladores que compilan aplicaciones web que dependen de la creación de conexiones a la red local de un usuario o al software que se ejecuta de forma local en su máquina. A partir de Chrome 138, puedes habilitar estas nuevas restricciones. Para ello, ve a chrome://flags/#local-network-access-check y establece la marca en "Habilitado (Bloqueo)".

¿Qué es el acceso a la red local?

El acceso a la red local restringe la capacidad de los sitios web para enviar solicitudes a los servidores de la red local de un usuario (incluidos los servidores que se ejecutan de forma local en la máquina del usuario) y requiere que el usuario otorgue permiso al sitio antes de que se puedan realizar esas solicitudes. La capacidad de solicitar este permiso se limita a contextos seguros.

Un mensaje con el texto "Buscar y conectarse a cualquier dispositivo de tu red local"
Ejemplo del mensaje de permiso de acceso a la red local de Chrome.

Muchas otras plataformas, como Android, iOS y MacOS, tienen permiso de acceso a la red local. Por ejemplo, es posible que hayas otorgado este permiso de acceso a la red local a la app de Google Home cuando configuraste dispositivos Google TV y Chromecast nuevos.

¿Qué tipos de solicitudes se ven afectadas?

Para el primer hito del Acceso a la red local, consideramos que una "solicitud de red local" es cualquier solicitud desde la red pública a una red local o un destino de bucle invertido.

Una red local es cualquier destino que se resuelve en el espacio de direcciones privadas definido en el artículo 3 de la RFC1918 en IPv4 (p.ej., 192.168.0.0/16), una dirección IPv6 asignada a IPv4 en la que la dirección IPv4 asignada es privada o una dirección IPv6 fuera de las subredes ::1/128, 2000::/3 y ff00::/8.

Puerta de enlace es cualquier destino que se resuelve en el espacio de “puente de enlace” (127.0.0.0/8) definido en el artículo 3.2.1.3 de la RFC1122 de IPv4, el espacio “local de vínculo” (169.254.0.0/16) definido en la RFC3927 de IPv4, el prefijo “dirección local única” (fcc00::/7) definido en el artículo 3 de la RFC4193 de IPv6 o el prefijo “local de vínculo” (fe80::/10) definido en el artículo 2.5.6 de la RFC4291 de IPv6.

Una red pública es cualquier otro destino.

Debido a que el permiso de acceso a la red local se restringe a contextos seguros y puede ser difícil migrar dispositivos de red local a HTTPS, las solicitudes de red local con control de permisos ahora estarán exentas de las verificaciones de contenido mixto si Chrome sabe que las solicitudes se enviarán a la red local antes de resolver el destino. Chrome sabe que una solicitud se dirige a la red local en los siguientes casos:

  • El nombre de host de la solicitud es un literal de IP privada (p.ej., 192.168.0.1).
  • El nombre de host de la solicitud es un dominio .local.
  • La llamada a fetch() se anota con la opción 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",
});

Qué cambiará en Chrome

Chrome 138

Nuestra versión inicial de Acceso a la red local está lista para las pruebas de participación en Chrome 138. Para habilitar el nuevo mensaje de permiso, los usuarios deben establecer chrome://flags#local-network-access-check en "Enabled (Blocking)". Esto admite el envío del mensaje de permiso de acceso a la red local para las solicitudes que se inician con la API de fetch() de JavaScript, la carga de subrecursos y la navegación de submarcos.

Hay un sitio de demostración disponible en https://local-network-access-testing.glitch.me/ para activar diferentes formas de solicitudes de red local.

Problemas conocidos y limitaciones

  • Por el momento, el nuevo mensaje de permiso solo se implementa en Chrome para computadoras. Estamos trabajando activamente para portarlo a Chrome para Android. (Se realiza un seguimiento en crbug.com/400455013).
  • Las conexiones de WebSocket (crbug.com/421156866), WebTransport (crbug.com/421216834) y WebRTC (crbug.com/421223919) a la red local aún no están restringidas en el permiso de LNA.
  • Actualmente, las solicitudes de red local de los trabajadores del servicio requieren que el origen del trabajador del servicio haya recibido previamente el permiso de acceso a la red local.
    • Si tu aplicación realiza solicitudes de red local desde un trabajador de servicio, actualmente deberás activar una solicitud de red local por separado desde tu aplicación para activar el mensaje de permiso. (Estamos trabajando en una forma para que los trabajadores activen el mensaje de permiso si hay un documento activo disponible; consulta crbug.com/404887282).

Chrome 139 y versiones posteriores

Nuestra intención es lanzar el acceso a la red local lo antes posible. Dado que es posible que algunos sitios necesiten tiempo adicional para actualizarse con las anotaciones de Acceso a la red local, agregaremos una prueba de origen para permitir que los sitios inhabiliten temporalmente el requisito de contextos seguros antes de que enviemos el Acceso a la red local de forma predeterminada. Esto debería proporcionar una ruta de migración más clara para los desarrolladores, en especial, si dependes del acceso a recursos de red local a través de HTTP (ya que estas solicitudes se bloquearían como contenido mixto si se solicitan desde una página HTTPS en navegadores que aún no admiten la exención de contenido mixto de acceso a red local).

También agregaremos una política empresarial de Chrome para controlar qué sitios pueden y no pueden realizar solicitudes de red local (otorgar o rechazar previamente el permiso a esos sitios). Esto permitirá que las instalaciones administradas de Chrome, como las que se encuentran en la configuración empresarial, eviten mostrar la advertencia para casos de uso previstos conocidos o bloqueen aún más los sitios y eviten que puedan solicitar el permiso.

Planeamos seguir integrando el permiso de Acceso a la red local con diferentes funciones que puedan enviar solicitudes a la red local. Por ejemplo, planeamos enviar pronto el acceso a la red local para las conexiones de WebSockets, WebTransport y WebRTC.

Compartiremos más información a medida que nos acerquemos al lanzamiento completo del Acceso a red local en Chrome.

Se buscan comentarios

Los comentarios anteriores sobre el desarrollo del Acceso a redes privadas fueron muy valiosos para guiarnos a nuestro nuevo enfoque de permisos de Acceso a la red local. Queremos agradecer nuevamente a todas las personas que participaron durante años.

Si desarrollas o usas un sitio web que depende de la creación de conexiones con la red local del usuario o el software que se ejecuta de forma local en su máquina, al equipo de Chrome le interesan tus comentarios y casos de uso. Puedes hacer dos acciones para ayudar: