Pregunta y alcance
El panel de control se sirve desde un origen público por HTTPS. Ocasionalmente llama a una impresora en una dirección privada y a un helper en localhost; también incrusta un iframe de un proveedor que no debe acceder a la red local. Explica cómo el navegador distingue los espacios de direcciones público, local y loopback, cuándo se requiere un permiso del usuario y cómo la página debe recuperarse ante una denegación.
Mantén la autorización de la aplicación, CORS y la autenticación del dispositivo dentro del alcance como capas separadas. El permiso del navegador es un límite de consentimiento del usuario, no una prueba de que una impresora pertenezca a la cuenta actual. Asume que el producto puede ofrecer una ruta de configuración manual cuando un navegador no implementa Local Network Access.
Qué está evaluando el entrevistador
La señal clave es si reconoces que una página pública que llama a un endpoint privado constituye un límite de seguridad. Una respuesta sólida nombra ataques de tipo CSRF contra routers e impresoras, y luego restringe el flujo con contexto seguro (secure context), clasificación del espacio de direcciones, estado del permiso y una lista de permitidos (allowlist) para el contenido incrustado.
El entrevistador también sondeará si confundes local-network con loopback-network, o si asumes que una verificación preliminar (preflight) de CORS exitosa concede acceso. Una buena respuesta mantiene la política, el permiso, el contenido mixto, CORS y la autenticación del dispositivo como barreras independientes.
Preguntas para clarificar antes de responder
- ¿Se conocen todos los destinos de antemano o los usuarios pueden ingresar direcciones IP arbitrarias? El escaneo arbitrario necesita un límite de producto diferente y no debe ocultarse detrás de un botón genérico de "conectar".
- ¿El helper está únicamente en
localhosto se puede alcanzar a través de una subred privada? Esto cambia si se necesita permiso de loopback o de red local. - ¿Puede un iframe de un proveedor o un marco anidado realizar la solicitud? De ser así, cada límite de marco debe delegar explícitamente la característica y sus posibles orígenes de navegación.
- ¿Qué navegadores y políticas empresariales se admiten? Los tiempos de despliegue difieren, por lo que una ruta de compatibilidad debe ser observable en lugar de debilitar la seguridad silenciosamente.
Un marco de respuesta de 30 segundos
"Mantendría el panel de control en HTTPS, clasificaría cada destino como público, local o loopback, y solicitaría únicamente el permiso del navegador correspondiente cuando sea necesario. La política de respuesta denegaría el acceso local al iframe del proveedor; si un iframe debe conectarse, su lista allow nombraría los orígenes exactos y todos los destinos de navegación. Verificaría el estado del permiso antes de la acción, mostraría por qué se necesita el acceso, manejaría las fallas de contenido mixto y CORS por separado, y proporcionaría una ruta de configuración manual para navegadores no compatibles. Las pruebas validarían que hosts arbitrarios y marcos de anuncios en producción nunca desencadenen una solicitud a la red local".
Respuesta detallada paso a paso
Paso 1: Definir el límite de confianza y los espacios de direcciones
Un sitio web público no debe enviar silenciosamente solicitudes que cambien el estado a un router, impresora o servicio de desarrollo del usuario. Modela tres clases de destino: las direcciones públicas son accesibles globalmente, las direcciones locales son accesibles solo en la red del usuario y las direcciones de loopback apuntan al mismo dispositivo. localhost no es equivalente a cualquier subred privada.
El inventario de solicitudes debe incluir fetch, cargas de subrecursos, WebSockets, WebTransport, WebRTC, solicitudes de service workers y navegación de marcos. Una biblioteca que abre un socket puede cruzar el mismo límite incluso cuando el código de la aplicación no contiene una llamada directa a fetch.
Paso 2: Requerir un contexto seguro y permiso explícito
Utiliza una página de nivel superior con HTTPS. En los navegadores compatibles, consulta el permiso relevante antes de intentar la acción en el dispositivo:
const localState = await navigator.permissions.query({ name: "local-network" });
const loopbackState = await navigator.permissions.query({ name: "loopback-network" });Trata granted, prompt y denied como estados del producto. Explica el propósito antes de activar una solicitud de permiso; ante una denegación, muestra un enlace de reparación o configuración manual en lugar de reintentar en un bucle. Una página HTTP debe considerarse no compatible para este flujo, incluso si un destino responde por casualidad.
Paso 3: Restringir los documentos incrustados
La respuesta de nivel superior puede delegar únicamente la característica y los orígenes que la necesitan. Un marco de proveedor no obtiene capacidad de red local:
Permissions-Policy: local-network=(self "https://dashboard.example"), loopback-network=(self "https://dashboard.example")Si un marco de configuración de confianza debe conectarse, delega de manera estricta:
<iframe src="https://setup.example" allow="local-network https://setup.example; loopback-network https://setup.example"></iframe>La cabecera y la política del iframe se intersectan. Un marco no puede ampliar una denegación del padre. Si el marco navega a otro origen que también realiza solicitudes locales, enumera ese origen explícitamente o deniega el acceso después de la navegación. Los marcos anidados necesitan la política en cada límite.
Paso 4: Separar el permiso del contenido mixto y CORS
El permiso no hace que una solicitud insegura sea universalmente válida. Algunas implementaciones de navegadores permiten endpoints HTTP locales seleccionados tras el consentimiento, mientras que otras comprobaciones de contenido mixto siguen aplicando. Utiliza los metadatos del espacio de direcciones de destino de la solicitud solo cuando el navegador y el contrato del endpoint lo admitan; no los uses como una vía de escape para un destino público.
CORS responde si el destino permite que el origen web lea una respuesta. No autoriza a una página pública a acceder a una impresora y no puede reemplazar la autenticación del dispositivo. Para un comando que cambie el estado, utiliza un desafío específico del dispositivo o un código de emparejamiento y haz que el comando sea idempotente.
Paso 5: Diseñar el fallback y la telemetría
Los navegadores no compatibles deben exponer una IP manual, un helper nativo o una ruta de emparejamiento guiada por el usuario. Registra la clase de destino, el estado del permiso, el resultado de la política, la capacidad del navegador, el resultado de CORS y el resultado de autenticación del dispositivo sin registrar credenciales ni respuestas locales sin procesar. Una alarma de producción debe dispararse si una versión provoca que una nueva clase de host solicite acceso local o si un marco de anuncios lo intenta.
Paso 6: Probar la matriz negativa
Prueba localhost, una IP privada, un nombre de host público que resuelve públicamente, un nombre de host público que resuelve localmente, una página HTTP, un permiso faltante, un permiso denegado, una delegación de iframe faltante, un marco anidado, una navegación a un origen no listado, una respuesta CORS bloqueada, una falla de autenticación del dispositivo y una dirección que cambia de clase durante la resolución DNS. Verifica que solo la acción prevista del usuario pueda activar una solicitud de permiso y que ningún reintento en segundo plano escanee un rango.
Respuesta de muestra de alta calidad
"Trataría las solicitudes de público a local como una capacidad que debe solicitarse y acotarse. El panel de control se mantiene en HTTPS, clasifica los destinos de la impresora y del helper por separado, verifica el estado de local-network o loopback-network y explica la solicitud antes de realizar una única petición acotada. La política de respuesta deniega ambas características al iframe del proveedor. Si se requiere un iframe de configuración confiable, su lista allow contiene solo el origen de configuración y cada origen al que pueda navegar.
Mantendría el permiso del navegador, las comprobaciones de contenido mixto, CORS y la autenticación del dispositivo como barreras separadas. Un navegador denegado o no compatible recibe un emparejamiento manual en lugar de solicitudes repetidas. Las pruebas cubren local, loopback, público, reclasificación de DNS, marcos anidados, falta de delegación, permiso denegado, falla de CORS y falla de autenticación del dispositivo. El despliegue de la versión se detiene si un anuncio o un host arbitrario puede activar una solicitud o petición de permiso".
Errores comunes
- Tratar cada IP privada como loopback → loopback y la red local tienen semánticas de permisos diferentes → clasifica el destino antes de seleccionar el permiso.
- Reintentar tras una denegación hasta que aparezca una solicitud de permiso → esto genera sorpresas y comportamientos similares a escaneos → muestra el contexto una vez y proporciona remediación.
- Asumir que CORS hace que una impresora sea confiable → CORS controla cómo se comparten las respuestas, no la identidad del dispositivo → empareja el dispositivo y autentica los comandos.
- Otorgar
local-network *a un marco de proveedor → las redirecciones y los documentos anidados pueden ampliar el conjunto de confianza → enumera orígenes exactos o deniega la delegación. - Depender de una prueba exclusiva de localhost → puede no ejercitar el límite de público a local → prueba desde un origen público HTTPS contra cada clase de dirección.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿Por qué localhost funcionó en desarrollo pero falló en producción?
El entorno de desarrollo puede ejecutarse desde un origen loopback o un navegador sin las nuevas restricciones. La producción es un origen público que cruza al espacio de loopback o local, por lo que el contexto seguro, el permiso, la política, el contenido mixto y las barreras de CORS se vuelven relevantes. Reproduce el escenario desde un origen de prueba público por HTTPS.
Pregunta de seguimiento 2: ¿Puede un iframe heredar el permiso de nivel superior automáticamente?
Solo dentro de las reglas de política y delegación. Un marco de origen cruzado necesita una concesión explícita de la característica y los marcos anidados necesitan su propia delegación. La decisión del usuario está vinculada al contexto de incrustación, pero no elude la ausencia de allow ni un origen de navegación no listado.
Pregunta de seguimiento 3: ¿Qué pasa si el DNS para agent.example cambia de público a privado?
Reclasifica la dirección resuelta y exige el permiso y la ruta de contexto seguro adecuados. No almacenes en caché una clasificación pública para siempre. Registra la transición de clasificación y falla de forma cerrada (fail closed) si el destino no está en el conjunto de objetivos aprobados por el producto.
Pregunta de seguimiento 4: ¿Por qué no basta con una solicitud de permiso para un comando de impresora?
La solicitud de permiso indica que el usuario permitió el acceso a la red desde el sitio; no autentica el dispositivo ni autoriza la operación solicitada. Empareja el dispositivo, vincula los comandos a una cuenta y un nonce, y haz que los reintentos sean idempotentes.