Resumen ejecutivo del riesgo

Descripción del fallo

Cuando un servidor web permite conexiones HTTP y HTTPS, los usuarios a menudo acceden inicialmente a la versión insegura (HTTP). Aunque el servidor redirija a HTTPS, esa primera conexión sin cifrar es vulnerable a ataques de Man-in-the-Middle (MitM) y SSL Stripping, donde un atacante puede interceptar el tráfico antes de que ocurra la redirección.

La cabecera Strict-Transport-Security le indica al navegador que nunca debe comunicarse con el dominio a través de HTTP. Automáticamente, el navegador transformará cualquier intento de conexión HTTP en una solicitud HTTPS segura en el lado del cliente, antes de enviar los datos a la red.

Alcance y condiciones previas

Evidencia o forma de validación

La condición se valida revisando si las respuestas HTTPS del servidor incluyen la cabecera Strict-Transport-Security. La comprobación posterior definida en esta guía utiliza una solicitud de encabezados con curl contra el dominio en producción.

Impacto técnico y de negocio

Paso a paso de remediación HSTS

La implementación consiste en inyectar la cabecera en las respuestas del servidor web. A continuación, se detallan las directivas para los entornos más comunes:

server {
  listen 443 ssl;
  server_name password.co;

  # Inyectar cabecera HSTS (Válida por 1 año, incluye subdominios)
  add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

  # ... resto de la configuración ...
}

<IfModule mod_headers.c>
   # Inyectar cabecera HSTS (Válida por 1 año, incluye subdominios)
   Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</IfModule>

Verificación de la solución

Para asegurarte de que la cabecera se está enviando correctamente, ejecuta el siguiente comando curl desde una terminal apuntando al dominio en producción:

curl -I https://password.co

Resultado esperado: Entre las líneas de la respuesta HTTP, debes confirmar la existencia exacta de la directiva:

HTTP/2 200
server: nginx
date: Sat, 11 Jul 2026 20:47:14 GMT
strict-transport-security: max-age=31536000; includeSubDomains

Plan de Rollback (Reversión)

Si por alguna razón la aplicación presenta fallos con subdominios antiguos que no soportan HTTPS, puedes mitigar el impacto reduciendo el tiempo de vida de la directiva a cero de forma temporal. Esto le indica a los navegadores que limpien la caché de HSTS inmediatamente:

Riesgos residuales y limitaciones

La política HSTS comienza a aplicarse después de que un navegador compatible recibe la cabecera por HTTPS, salvo que el dominio se encuentre precargado en una lista HSTS del navegador. Además, el uso de includeSubDomains exige que todos los subdominios relevantes puedan operar correctamente mediante HTTPS.

La configuración de HSTS fortalece el transporte web, pero no reemplaza la gestión de certificados, la corrección del contenido mixto, la configuración segura de TLS ni el monitoreo de las cabeceras en producción.

Recomendaciones complementarias

Antes de ampliar la política a todos los subdominios, verifica dependencias heredadas, servicios externos y puntos de integración. Documenta el cambio, conserva una ruta de reversión y valida la cabecera después de cada despliegue o modificación de la infraestructura.

Rol de Password Consulting Services

Password puede acompañar la evaluación de configuraciones web, la identificación de exposiciones y la validación posterior de los controles mediante Pentesting Avanzado y pruebas de seguridad de aplicaciones. El propósito es reducir la superficie de ataque y aportar evidencia técnica para priorizar mejoras.

Preguntas frecuentes sobre la implementación de HSTS