Generador y validador de política HSTS | Cabecera y requisitos de preload en una sola pantalla

Selecciona un max-age, activa includeSubDomains y preload, y obtén una cabecera Strict-Transport-Security lista para pegar junto a una comprobación de cinco puntos PASA / FALLA / AVISO frente a las reglas de la preload-list de Chromium.

💡 Sobre esta herramienta

HTTP Strict Transport Security (HSTS) es una cabecera de respuesta que indica al navegador "usa siempre HTTPS para este dominio". Escribir la cabecera es lo fácil. Lo que genera más dudas es la lista de precarga (preload list): una lista mantenida por el proyecto Chromium que los navegadores incorporan de fábrica. Si tu dominio entra en ella, HTTPS se aplica antes incluso de la primera petición, pero el registro exige tres condiciones simultáneas: max-age de al menos un año (31536000 segundos), la directiva includeSubDomains y la directiva preload.

Si envías una cabecera que incumple cualquiera de estos requisitos, hstspreload.org la rechaza y pierdes un ciclo de corrección y reenvío. Y al revés: añadir preload sin entender sus implicaciones obliga a usar HTTPS en todos tus subdominios —incluidos paneles internos y hosts antiguos— y deja a usuarios sin acceso. Esta herramienta coloca el generador de la cabecera y la lista de comprobación una al lado de la otra, para que confirmes antes de enviar que tu cabecera cumple las reglas y que no has creado una combinación contradictoria como max-age=0 junto a preload.

Los valores predefinidos cubren 0 (revocar), 5 minutos, 1 día, 1 semana, 30 días, 180 días, 1 año y 2 años. Para un primer despliegue, lo prudente es empezar con un valor corto y aumentarlo de forma escalonada.

🧐 Preguntas Frecuentes

P. ¿Cuál es el max-age mínimo para la preload-list? R. El registro exige al menos 31536000 segundos (1 año). Comprueba que la fila "max-age es al menos 31536000 segundos" pase a PASA. Los 180 días (15552000 s) no alcanzan el requisito de 1 año, así que no bastan para el registro.

P. ¿Qué hace exactamente max-age=0? R. Indica al navegador que borre cualquier política HSTS almacenada para el host, útil cuando quieres revertir HSTS. Combinarlo con preload produce una contradicción, por eso esa pareja aparece como FALLA en la lista.

P. ¿Qué alcance tiene includeSubDomains? R. Aplica la política a todos los subdominios, no solo al dominio raíz. Es obligatorio para preload, pero cualquier subdominio que no esté en HTTPS quedará inaccesible, así que inventaría tus subdominios antes de activarlo.

P. ¿Puedo deshacer un registro en preload? R. Puedes solicitar la baja, pero las cachés de los navegadores tardan meses en actualizarse. Trata preload como algo prácticamente irreversible y decide en consecuencia.

P. ¿Por qué aumentar max-age de forma gradual en vez de saltar a un año? R. Un valor corto mantiene bajo el coste de revertir si detectas una mala configuración. La escalera habitual es 5 min → 1 día → 1 semana → 1 mes → 1 año.

📚 Datos Curiosos

HSTS está definido en el RFC 6797, pero la preload-list no forma parte de ningún RFC: existe como política pública del proyecto Chromium en hstspreload.org. Es decir, trabajas con dos capas: una cabecera estandarizada y, encima, una lista impulsada por los fabricantes de navegadores.

Esa lista no es exclusiva de Chrome. Firefox, Safari y Edge también la incorporan, de modo que un único registro se propaga a todos los navegadores principales. Una técnica que se ve en foros de seguridad: registrar un dominio recién comprado en la preload-list de inmediato, para que la aplicación de HTTPS comience desde un estado sin historial previo en HTTP plano.