Cómo configurar HSTS sin quedarte fuera

HSTS es sencillo hasta que deja de serlo

HTTP Strict Transport Security, normalmente abreviado como HSTS, indica a los navegadores: «para este sitio, usa siempre HTTPS». Cuando un navegador recibe la cabecera a través de una conexión HTTPS válida, recuerda la regla durante el tiempo que especifiques.

Eso es útil. Evita ataques de degradación de protocolo, reduce las solicitudes inseguras accidentales y evita ese momento incómodo en el que un usuario escribe example.com y toca brevemente HTTP en claro antes de ser redirigido.

También es persistente. Si publicas una política HSTS incorrecta, los navegadores pueden seguir aplicándola mucho después de que retires la cabecera de tu servidor. Así es como los equipos se quedan fuera: no exactamente de su propio panel de administración, sino de los navegadores de los usuarios, subdominios, sistemas de staging, endpoints heredados y servicios olvidados que no están preparados para HTTPS obligatorio.

El objetivo no es evitar HSTS. El objetivo es desplegarlo como una migración, no como un interruptor.

Qué hace realmente la cabecera HSTS

Una cabecera HSTS típica tiene este aspecto:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Tiene tres partes importantes:

• max-age: durante cuánto tiempo, en segundos, el navegador debe aplicar HTTPS para este host.
• includeSubDomains: si la regla también se aplica a todos los subdominios.
• preload: una señal de que quieres que el dominio se incluya en las listas de precarga de los navegadores.

El navegador solo confía en esta cabecera cuando la recibe a través de HTTPS válido. Si el certificado no es válido, ha caducado o no coincide, el navegador no debería aceptar una nueva política HSTS desde esa respuesta.

Una vez almacenada la política, los intentos futuros de visitar http://example.com son actualizados por el navegador a https://example.com antes de que se envíe la solicitud. Esa es la mejora de privacidad: la solicitud insegura nunca sale del dispositivo.

Los escenarios de bloqueo que conviene evitar

La mayoría de los fallos de HSTS no los causa el sitio web principal. Ocurren en los bordes.

1. Un subdominio olvidado no está preparado para HTTPS

includeSubDomains suena ordenado, pero es absoluto. Si lo configuras en example.com, se aplica a:

• www.example.com
• api.example.com
• old-crm.example.com
• printer-setup.example.com
• staging.example.com
• cualquier otra cosa bajo ese dominio

Si alguno de esos hosts no puede servir HTTPS válido, los usuarios con la política HSTS en caché no podrán acceder a ellos por HTTP.

2. Un certificado caduca

Sin HSTS, a veces los usuarios hacen clic para continuar pese a las advertencias de certificado. No es una buena práctica de seguridad, pero ocurre.

Con HSTS, los navegadores modernos no permiten omitir fácilmente los errores de certificado para ese host. Esa es la idea. También significa que la renovación de certificados debe ser aburrida, monitorizada y probada.

3. Las herramientas de staging o internas viven bajo el dominio de producción

Colocar herramientas internas bajo *.example.com puede volverse doloroso cuando el dominio padre usa includeSubDomains. Si esas herramientas usan certificados autofirmados, autoridades de certificación privadas, configuraciones TLS antiguas o directamente no usan HTTPS, HSTS expondrá el atajo.

Esta es una razón por la que muchos equipos mantienen los sistemas internos y experimentales bajo un dominio separado que tiene su propia política de seguridad.

4. Preload se trata como una casilla rutinaria

La precarga de HSTS no es simplemente otra directiva. Significa que tu dominio puede distribuirse dentro de los navegadores como solo HTTPS antes de que cualquier usuario haya visitado tu sitio.

Eso cierra la brecha de la «primera visita», pero es mucho más difícil de deshacer. La eliminación de las listas de precarga puede tardar semanas o meses en llegar a los usuarios, según los ciclos de lanzamiento de los navegadores. Preload es adecuado para dominios estables y maduros. No es adecuado para un sitio que aún está descubriendo su inventario de subdominios.

Un plan de despliegue seguro

Paso 1: Audita todos los nombres de host que controlas

Antes de configurar includeSubDomains, enumera todos los nombres de host bajo el dominio. Los registros DNS son un comienzo, pero no toda la historia. Revisa configuraciones de CDN, paneles de hosting, nombres de host relacionados con correo electrónico, herramientas antiguas de marketing, buckets de almacenamiento y documentación interna.

Para cada nombre de host, responde:

• ¿Sirve HTTP, HTTPS o ambos?
• ¿El certificado HTTPS es válido y se renueva automáticamente?
• ¿Redirige HTTP a HTTPS de forma limpia?
• ¿Está pensado para ser público?
• ¿Sigue siendo necesario?

Si tu equipo ya tiene hábitos de depuración de cabeceras en producción, esto encaja de forma natural junto a las comprobaciones de redirecciones y cabeceras. Cubrimos ese flujo de trabajo en un pequeño kit de herramientas para depurar redirecciones y cabeceras HTTP en producción.

Paso 2: Arregla HTTPS antes de añadir HSTS

HSTS no convierte una configuración HTTPS rota en segura. Solo hace que HTTPS sea obligatorio.

Antes de habilitarlo, verifica:

• Los certificados TLS cubren los nombres de host correctos.
• Los certificados se renuevan automáticamente.
• HTTP redirige a HTTPS con un único salto limpio siempre que sea posible.
• Las redirecciones del host canónico son coherentes, por ejemplo de no-www a www, o al revés.
• Los recursos de la aplicación no dependen de URLs http:// inseguras.

El contenido mixto es menos común que antes, pero todavía aparece en temas antiguos de CMS, fragmentos de analítica, medios incrustados y rutas de imágenes escritas a mano.

Paso 3: Empieza con un max-age muy corto

No empieces con un año. Empieza con cinco minutos:

Strict-Transport-Security: max-age=300

Despliégalo solo en el nombre de host que estás probando, normalmente el sitio web de producción canónico. Deja fuera includeSubDomains por ahora.

Después prueba en navegadores reales y con solicitudes de línea de comandos:

curl -I https://example.com

Deberías ver exactamente una cabecera Strict-Transport-Security. Las cabeceras HSTS duplicadas desde un servidor de aplicación y una CDN son una fuente común de confusión. Los navegadores suelen aplicar la política efectiva, pero las personas que depuran un incidente no necesitan ambigüedad.

Paso 4: Aumenta gradualmente

Si nada se rompe, aumenta la duración por etapas:

Strict-Transport-Security: max-age=86400

Luego:

Strict-Transport-Security: max-age=604800

Y después quizá:

Strict-Transport-Security: max-age=2592000

Un calendario práctico es:

• 5 minutos
• 1 día
• 1 semana
• 1 mes
• 6 meses o 1 año

No hay premio por ir deprisa. El objetivo del despliegue gradual es dar tiempo a tu monitorización, a la bandeja de soporte y a los casos límite para que te digan qué se le escapó a tu lista de comprobación.

Paso 5: Añade includeSubDomains solo cuando la auditoría sea real

Cuando todos los subdominios públicos estén preparados para HTTPS, puedes considerar:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Este es el momento de ser conservador. Si un servicio heredado todavía necesita HTTP, no añadas includeSubDomains al dominio padre. Migra ese servicio, muévelo a otro dominio o acepta que tu política HSTS debe seguir siendo más estrecha por ahora.

Las cabeceras de seguridad deben reflejar la realidad. No deberían usarse como carteles motivacionales para una infraestructura que esperas tener más adelante.

Paso 6: Trata preload como un proyecto aparte

Considera preload solo cuando todo lo siguiente sea cierto:

• El dominio y todos los subdominios admiten HTTPS válido.
• HTTP redirige a HTTPS.
• La cabecera HSTS usa un max-age de al menos 31536000 segundos.
• La cabecera incluye includeSubDomains.
• La cabecera incluye preload.
• Tienes la seguridad de que no necesitarás HTTP en claro en ninguna parte bajo el dominio.

Una cabecera preparada para preload tiene este aspecto:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Enviar un dominio a la lista de precarga es un compromiso a largo plazo. Si el sitio es un micrositio de campaña, un dominio temporal de producto o un dominio con límites de propiedad poco claros, omítelo.

Ejemplos de configuración

Nginx

Usa always para que la cabecera también se envíe en respuestas de error:

add_header Strict-Transport-Security "max-age=300" always;

Cuando el despliegue sea estable:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Apache

Con mod_headers habilitado:

Header always set Strict-Transport-Security "max-age=300"

Más adelante:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

CDN o plataforma de borde

Si tu CDN configura cabeceras de respuesta, prefiere gestionar HSTS en un solo lugar. No configures una política en el origen y otra en el borde salvo que tengas una razón muy clara.

Comprueba también si la CDN aplica cabeceras a redirecciones, errores en caché y páginas de error personalizadas. Un sitio de producción no es solo su respuesta 200 OK.

Cómo deshacer HSTS de forma segura

Si necesitas deshabilitar HSTS, envía:

Strict-Transport-Security: max-age=0

Pero hay una trampa: el navegador debe poder llegar correctamente al sitio mediante HTTPS válido para recibir esa cabecera. Si el propio HTTPS está roto, los usuarios con una política HSTS en caché no pueden obtener la instrucción que la borraría.

Así que el orden habitual de recuperación es:

1. Restaurar HTTPS válido.
2. Servir Strict-Transport-Security: max-age=0.
3. Mantenerlo el tiempo suficiente para que los usuarios que regresan lo reciban.
4. Eliminar o sustituir la cabecera después de que se resuelva el incidente.

Si el dominio está precargado, servir max-age=0 no basta para perfiles de navegador nuevos. También necesitas solicitar la eliminación de la lista de precarga y esperar a que ese cambio se distribuya mediante actualizaciones de los navegadores.

Lista de comprobación antes de publicar

Usa esta lista antes de aumentar max-age o añadir includeSubDomains:

• La URL HTTPS canónica devuelve un certificado válido.
• HTTP redirige a HTTPS.
• Solo hay una cabecera HSTS.
• La cabecera aparece en redirecciones y respuestas de error cuando corresponde.
• Todos los subdominios públicos tienen HTTPS válido.
• La renovación de certificados está monitorizada.
• Ningún sistema interno crítico depende de HTTP bajo el mismo dominio padre.
• Preload se ha debatido explícitamente, no se ha añadido por costumbre.

Lighthouse también puede señalar cabeceras de seguridad ausentes o débiles en algunos contextos, pero no debería ser tu único método de verificación. Si lo usas como parte de una revisión más amplia, lee los hallazgos como señales y no como veredictos; la misma mentalidad se aplica cuando lees un informe de Lighthouse sin entrar en pánico.

<!-- tool-cta:start -->

💡 Prueba esto: Antes y después de cada cambio de HSTS, inspecciona la respuesta Strict-Transport-Security con Get Headers para confirmar que max-age, includeSubDomains y preload son los que esperas.

<!-- tool-cta:end -->

El argumento de privacidad para HSTS

HSTS suele presentarse como una cabecera de seguridad, y lo es. También tiene un beneficio de privacidad: reduce la probabilidad de que la primera solicitud de un usuario se filtre por HTTP en claro en una red no fiable.

Eso importa en el Wi-Fi de aeropuertos, redes de hoteles, redes corporativas para invitados y cualquier lugar donde el tráfico de un usuario pueda ser observado o modificado. Una solicitud HTTP en claro puede exponer el nombre de host, la ruta, cookies sin la marca Secure y otros detalles de la solicitud. HTTPS no es magia, pero forzarlo de forma coherente elimina toda una clase de fugas evitables.

Los mejores despliegues de HSTS son poco interesantes. Se implementan despacio, están respaldados por certificados fiables y son lo bastante aburridos como para que nadie los note. Eso es exactamente lo que quieres de una cabecera cuyo modo de fallo puede ser dramático.