Nuevo mensaje de permiso para el acceso a la red local

Chris Thompson
Chris Thompson

Publicado el 9 de junio de 2025

Chrome agregará una nueva solicitud de permiso para los sitios que se conecten a la red local de un usuario como parte de la especificación de acceso a la red local. El objetivo es proteger a los usuarios de 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 y crear huellas digitales de la red local del usuario.

Para comprender cómo este cambio afecta el ecosistema web, el equipo de Chrome busca comentarios de los desarrolladores que crean aplicaciones web que dependen de la conexión 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 configura la marca como "Habilitada (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 servidores en la red local de un usuario (incluidos los servidores que se ejecutan de forma local en la máquina del usuario), lo que requiere que el usuario otorgue permiso al sitio antes de que se puedan realizar dichas solicitudes. La capacidad de solicitar este permiso está restringida 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 un permiso de acceso a la red local. Por ejemplo, es posible que hayas otorgado este permiso para acceder a la red local a la app de Google Home cuando configuraste dispositivos Google TV y Chromecast nuevos.

¿Qué tipos de solicitudes se ven afectados?

Para el primer hito del acceso a la red local, consideramos que una "solicitud de red local" es cualquier solicitud de 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 la sección 3 de 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.

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

Para ver una asignación completa de direcciones IP a espacios de direcciones, consulta la tabla en la especificación de acceso a la red local.

Una red pública es cualquier otro destino.

Dado que el permiso de acceso a la red local está restringido a contextos seguros y puede ser difícil migrar los dispositivos de red local a HTTPS, las solicitudes de red local protegidas por permisos ahora estarán exentas de las verificaciones de contenido mixto si Chrome sabe que las solicitudes se dirigirá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 del acceso a la red local está lista para las pruebas de participación en Chrome 138. Los usuarios pueden habilitar el nuevo mensaje de permiso configurando chrome://flags#local-network-access-check como "Habilitado (bloqueo)". Esto admite la activación del mensaje de permiso de acceso a la red local para las solicitudes iniciadas con la API de fetch() de JavaScript, la carga de subrecursos y la navegación de subframes.

Hay un sitio de demostración disponible en https://lna-testing.notyetsecure.com/ para activar diferentes tipos de solicitudes de red local.

Problemas conocidos y limitaciones

  • Las conexiones de WebSockets (crbug.com/421156866), WebTransport (crbug.com/421216834) y WebRTC (crbug.com/421223919) a la red local aún no están controladas por el permiso de LNA.
  • Las solicitudes de red local de Service Workers y Shared Workers requieren que el origen del trabajador haya recibido previamente el permiso de acceso a la red local.
    • Si tu aplicación realiza solicitudes de red local desde un service worker, deberás activar por separado una solicitud de red local 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

Nuestro objetivo es lanzar el acceso a la red local lo antes posible. Como sabemos que algunos sitios pueden necesitar 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 lancemos 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 la 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 la red local).

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

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

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

Se buscan comentarios

Los comentarios anteriores sobre el desarrollo del acceso a la red privada fueron muy valiosos para guiarnos hacia nuestro nuevo enfoque de permiso de acceso a la red local. Queremos agradecer una vez más a todas las personas que participaron a lo largo de los años.

Si desarrollas o eres usuario de un sitio web que depende de la conexión a la red local del usuario o al software que se ejecuta de forma local en la máquina del usuario, al equipo de Chrome le interesa conocer tus comentarios y casos de uso. Puedes hacer dos cosas para ayudar: