Planteamiento y alcance
Tu API autenticada escucha tanto en HTTP como en HTTPS, y las solicitudes HTTP reciben una redirección 301 a HTTPS. Explica el riesgo, los cambios en el servidor y el cliente, y un plan de migración para clientes heredados. El planteamiento se basa en el Internet-Draft de mayo de 2026 del grupo de trabajo HTTPAPI; sigue siendo un trabajo en progreso y no es un RFC final.
Qué está evaluando el entrevistador
- Reconocer que las credenciales ya han cruzado una red de texto plano antes de que ocurra una redirección.
- Combinar HSTS, registros DNS HTTPS, bloqueo de conexiones y cookies Secure.
- Manejar hosts compartidos, clientes heredados, proxies y la revocación de credenciales.
- Demostrar la reducción de riesgos con señales medibles en lugar de limitarse a decir "usa HTTPS".
Preguntas para aclarar antes de responder
- ¿Utilizan HTTP y HTTPS el mismo hostname y listener?
- ¿Son las credenciales tokens Bearer, cookies, claves de API o firmas de solicitud?
- ¿Existen clientes heredados, proxies empresariales o emisores internos que no puedan actualizarse de inmediato?
- ¿El punto de entrada HTTP también sirve recursos no autenticados?
- ¿Ya utilizas HSTS, registros DNS HTTPS, rotación de claves y registros de auditoría?
Estructura de respuesta en 30 segundos
Una redirección no puede recuperar credenciales que ya fueron enviadas en texto plano; un observador pasivo puede copiar un token Bearer o una cookie. Es preferible hacer que la entrada HTTP falle antes de una conexión autenticada, usar registros DNS HTTPS y HSTS para reducir malas configuraciones en el primer uso y en usos repetidos, establecer Secure en las cookies y hacer que los clientes rechacen URLs inseguras por defecto. Si el bloqueo inmediato es imposible, devuelve el mismo 403 para cada solicitud en texto plano que contenga credenciales y revoca las credenciales que puedan haberse filtrado. Migra con métricas, un período de transición y capacidad de rollback.
Análisis detallado paso a paso
1. Explicar cuándo ocurre la fuga
El cliente envía primero una solicitud HTTP, que potencialmente contiene Authorization, una cookie o una clave de API. Un 301 posterior no puede borrar lo que ya cruzó la red. Un atacante puede reproducir un token Bearer o una cookie. Un reintento exitoso por HTTPS también puede ocultar una mala configuración del cliente durante mucho tiempo.
2. Diseñar el punto de entrada del servidor
Para los endpoints autenticados, primero deshabilita la escucha pública en texto plano o restringe el puerto 80 a una red explícitamente confiable. No trates un 301 como un control de seguridad. Si un host compartido debe mantener HTTP, el gateway debe reconocer las solicitudes que contienen credenciales y devolver el mismo 403 sin revelar si una credencial es válida.
HTTP/1.1 403 Forbidden
Cache-Control: no-store
Content-Length: 0La respuesta no debe diferir entre credenciales válidas e inválidas, o de lo contrario un atacante obtendrá un oráculo de prueba para valores robados.
3. Reducir errores del cliente en el primer uso
Los registros DNS HTTPS pueden indicarle al cliente que use una conexión segura durante el establecimiento de la conexión. HSTS actualiza conexiones posteriores después de una visita HTTPS exitosa. Ninguno es perfecto: HSTS depende de esa conexión previa y de la persistencia del cliente, mientras que los registros DNS pueden ser bloqueados. Los SDKs, CLIs y la validación de configuraciones deben rechazar http por defecto y proporcionar un mensaje de remediación procesable.
4. Restringir el uso de credenciales
Las cookies deben llevar el atributo Secure. Los tokens deben limitarse a contextos seguros, con firmas vinculadas a la solicitud o a la conexión donde sea apropiado. La revocación difiere según el tipo de credencial: las claves de API reproducibles, los tokens Bearer y las cookies generalmente requieren revocación inmediata, mientras que una firma derivada no falsificable podría no requerirla.
5. Manejar credenciales expuestas
Trata cualquier credencial recibida sobre texto plano como potencialmente comprometida. El servidor puede devolver un 403 uniforme primero y luego explicar "credencial revocada" en el siguiente uso seguro. Registra la revocación en un log de auditoría, notifica al propietario para que la rote y nunca coloques valores confidenciales en logs, cachés o cuerpos de error.
6. Migrar de forma segura
Rechaza HTTP primero en SDKs y entornos de prueba, luego deshabilita el punto de entrada en texto plano para nuevos inquilinos y, finalmente, migra a los inquilinos heredados en lotes. Ofrece a los clientes que requieren un proxy antiguo un endpoint de transición temporal que nunca acepte credenciales. Establece una fecha límite, monitorea las tasas de 403 y la finalización de rotaciones, y traslada las APIs autenticadas a un hostname o política de gateway independientes cuando los recursos públicos aún necesiten HTTP.
7. Verificar los controles
Usa capturas de paquetes para confirmar que Authorization, cookies y claves de API nunca aparezcan en texto plano. Verifica el fallo de conexión y el comportamiento de 403, luego prueba el almacenamiento en caché de HSTS, la primera visita, proxies, reintentos y rollback. Rastrea solicitudes en texto plano, solicitudes en texto plano con credenciales, revocaciones automáticas, falsos positivos de 403, proporción de clientes heredados y la finalización de la migración.
Ejemplo de respuesta de alta calidad
No trataría un 301 como la solución de seguridad para una API autenticada, porque la credencial ya ha cruzado una red de texto plano antes de la redirección. Un observador pasivo puede copiar un token Bearer o una cookie, y un reintento exitoso por HTTPS puede ocultar el error del cliente.
El servidor debería primero deshabilitar HTTP público en los endpoints autenticados. Si un host compartido no puede hacer eso de inmediato, el gateway devuelve el mismo 403 para cada solicitud HTTP que contenga credenciales, no revela la validez de la credencial y la marca como potencialmente expuesta. Los tokens reproducibles, claves de API y cookies se revocan y rotan. Los SDKs, CLIs y comprobaciones de configuración rechazan http por defecto; los registros DNS HTTPS y HSTS reducen errores en el primer uso y usos repetidos, y las cookies llevan Secure.
Migra en etapas a través de entornos de prueba, nuevos inquilinos e inquilinos heredados. Ofrece a los proxies empresariales una ruta de transición corta que no acepte credenciales. Verifica con capturas de paquetes y mide solicitudes en texto plano, solicitudes en texto plano con credenciales, finalización de revocación y rotación, falsos positivos de 403 y la proporción de clientes heredados. El documento de la IETF aún es un borrador, por lo que los compromisos de implementación siguen siendo ajustables.
Errores comunes
- Asumir que una redirección a HTTPS protege un encabezado Authorization o una cookie que ya fue enviada.
- Configurar únicamente HSTS ignorando el primer uso, los clientes heredados y los SDKs que no son navegadores.
- Devolver respuestas en texto plano diferentes para credenciales válidas e inválidas.
- Tratar todas las credenciales como idénticas e ignorar firmas derivadas frente a tokens reproducibles.
- Eliminar HTTP sin un plan de migración, monitoreo, revocación o rollback.
Preguntas de seguimiento y respuestas
¿Qué pasa si el punto de entrada HTTP todavía sirve recursos públicos?
Mueve la API autenticada a un hostname separado o aísla rutas y encabezados de credenciales en el gateway. Los recursos públicos pueden tener su propia política de redirección; los endpoints autenticados deben rechazar solicitudes en texto plano que contengan credenciales.
¿Resuelve HSTS la primera visita?
No por completo. HSTS necesita una conexión HTTPS previa exitosa y persistencia en el cliente. Los SDKs, validaciones de configuración, registros DNS HTTPS y comprobaciones de despliegue deben cubrir también la primera conexión.
¿Cuándo deben revocarse las credenciales?
Trata las credenciales vistas en texto plano como potencialmente expuestas. Revoca y rota tokens reproducibles, claves de API y cookies. Para una firma derivada no falsificable, decide según el modelo de amenazas si la revocación es necesaria.
¿Cómo se evita una migración disruptiva?
Habilita primero el rechazo en pruebas y nuevos inquilinos, observa a los clientes heredados y los falsos positivos de 403, y luego migra en lotes. Mantén un endpoint de transición temporal que no acepte credenciales y elimínalo tras una fecha límite clara.