HSTS preload: requisitos para entrar en la lista de precarga, riesgos y cómo comprobar tu cabecera

1. Qué es la lista de precarga HSTS

HTTP Strict Transport Security se define en el RFC 6797. El servidor envía Strict-Transport-Security: max-age=… por HTTPS y el navegador recuerda durante max-age segundos que a ese host solo puede conectarse por HTTPS. Mientras el navegador del visitante no haya recibido la cabecera al menos una vez, nada protege la primera petición http:// en claro, y alguien en la misma red puede interceptarla. El RFC describe esta debilidad del primer contacto y propone las políticas preconfiguradas como una posible respuesta.

La lista de precarga es esa respuesta llevada a la práctica. La mantiene el proyecto Chromium y las entradas nuevas se escriben directamente en el código fuente de Chrome. Según la página de HSTS de Chromium y hstspreload.org, Firefox, Safari y Edge mantienen sus propias listas basadas en la de Chrome. En cualquier versión del navegador que incluya la entrada, un dominio precargado es solo HTTPS desde el primer arranque, y como los envíos deben llevar includeSubDomains, también lo es cada nombre que cuelga de él.

Hay tres detalles que se suelen malinterpretar:

• La directiva preload no hace nada en el navegador. No forma parte del RFC 6797, y los navegadores ignoran las directivas que no reconocen. Sirve para decir a quienes mantienen la lista que el titular del dominio acepta la inclusión. En cuanto tu cabecera la lleva, cualquiera puede enviar tu dominio con el formulario.
• Solo entran dominios registrables completos. Se envía example.com, no www.example.com ni tienda.example.com, y la entrada abarca todos los subdominios, incluidos los internos que no son accesibles desde internet.
• Algunos dominios de primer nivel están precargados enteros. Cualquier dominio bajo .app o .dev, por ejemplo, ya es solo HTTPS en los navegadores que usan la lista, lo haya enviado o no su titular.

2. ¿Sigue haciendo falta la precarga?

Para la mayoría de los sitios, probablemente no. La propia web de envío dice ahora que HSTS es recomendable, pero la precarga no. Chrome y Safari intentan HTTPS automáticamente en las navegaciones que empiezan por http://, haya o no política HSTS, así que el hueco de la primera visita que la precarga venía a cerrar se ha estrechado mucho. Según hstspreload.org, la precarga solo añade protección cuando esas mejoras automáticas fallan por culpa de un atacante activo, y su beneficio es mínimo comparado con el de HSTS.

Aun así, puede tener sentido si se dan todas estas condiciones:

• te preocupa una degradación a HTTP en la primerísima visita, por ejemplo porque tus usuarios inician sesión o pagan desde redes públicas;
• todos los subdominios actuales y futuros, incluidos los internos y los alojados por proveedores, pueden servir HTTPS con un certificado válido;
• piensas conservar el dominio, y HTTPS en él, durante años.

Descártala, o aplázala, si hay equipos o proveedores que gestionan subdominios que no controlas del todo, si tienes hosts internos bajo el dominio público, si el dominio es de una campaña de vida corta o si podrías venderlo o traspasarlo: la entrada acompaña al dominio hasta su siguiente titular mientras nadie pida retirarla. Una cabecera HSTS bien configurada sin preload ya protege a cada visitante que vuelve.

3. Los requisitos exactos para enviar tu dominio

hstspreload.org revisa estas condiciones cuando envías el dominio, y tienes que seguir reuniéndolas después: los dominios que dejan de hacerlo pueden ser retirados, y quitar preload de la cabecera permite pedir la retirada de inmediato.

La regla de las redirecciones pilla a muchos sitios. Si https://example.com/ redirige a https://www.example.com/, esa misma respuesta de redirección debe llevar la cabecera completa. La de la página www no cuenta, porque una política fijada por www.example.com nunca se aplica al dominio base. Una cabecera que pasa la revisión tiene este aspecto:

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

4. Los riesgos: por qué cuesta tanto dar marcha atrás

• Salir de la lista lleva meses. La retirada es un cambio en el código que llega a la gente con las actualizaciones del navegador. La página de retirada indica que puede tardar de 6 a 12 semanas en llegar a la mayoría de los usuarios de Chrome, y quizá más en otros navegadores. Un navegador que nunca se actualiza conserva la entrada antigua.
• Los subdominios sin HTTPS dejan de funcionar. Casos típicos: hosts de intranet que solo resuelven en el DNS interno, paneles de impresoras, routers y equipos de almacenamiento con certificados autofirmados, servidores de pruebas olvidados y servicios de proveedores bajo un CNAME, como un centro de ayuda, una página de estado o los enlaces de seguimiento de clics del correo, que solo responden por HTTP. En un navegador con tu dominio precargado fallan sin posibilidad de saltarse el error.
• Los fallos de certificado se vuelven bloqueantes. En un host HSTS, el RFC 6797 obliga al navegador a cortar la conexión ante cualquier error de certificado sin dejar que el visitante continúe. Un certificado caducado en cualquier subdominio deja fuera a todo el mundo hasta que se sustituye, así que automatiza la renovación y vigila las fechas de caducidad antes de enviar el dominio.
• Quien ya te visitó conserva su política. Salir de la lista no borra la política que los navegadores aprendieron de tu cabecera. Con un max-age de dos años, esa copia dura dos años, salvo que el visitante vuelva y reciba max-age=0 por HTTPS.
• Envíos accidentales. Basta una cabecera copiada de una plantilla con preload ya incluido para que cualquiera pueda enviar tu dominio. Deja la directiva fuera hasta terminar el plan de la sección siguiente.

5. Un plan de max-age por etapas antes del envío

hstspreload.org recomienda subir max-age por etapas, con includeSubDomains desde la primera. En cada etapa, busca páginas rotas y vigila tus métricas (tráfico, inicios de sesión, ingresos), corrige lo que aparezca y espera como mínimo el max-age completo de esa etapa antes de pasar a la siguiente. Puedes recorrer las etapas primero con un grupo de prueba, pero después tienes que hacerlo con todos los usuarios.

En nginx, envía la cabecera desde el bloque server de HTTPS con el parámetro always, para que también la lleven las páginas de error, y mantén la redirección HTTP en el mismo host. Una línea add_header dentro de un bloque location sustituye allí a las cabeceras definidas en el nivel server (módulo de cabeceras de nginx).

server {
    listen 80;
    server_name example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    # etapa 1: cambia el valor en cada etapa
    add_header Strict-Transport-Security "max-age=300; includeSubDomains" always;
}

Solo la subida por etapas lleva más de cinco semanas. Tras el envío, según hstspreload.org, una entrada nueva puede tardar varios meses en llegar a la versión estable de Chrome, así que la precarga nunca es un arreglo rápido para una fecha de lanzamiento.

6. Cómo comprobar tu cabecera HSTS

Desde un terminal, revisa las tres respuestas que importan:

curl -sS -D - -o /dev/null http://example.com/
curl -sS -D - -o /dev/null https://example.com/
curl -sS -D - -o /dev/null https://www.example.com/

La primera debe devolver 301 o 308 con Location: https://example.com/; no necesita cabecera HSTS, porque los navegadores ignoran la que llega por HTTP sin cifrar. La segunda debe llevar strict-transport-security con las tres directivas, aunque sea a su vez una redirección a www. La tercera también debería enviarla, porque quien solo abre www nunca recibe la política del dominio base. En Windows, usa curl.exe y -o NUL.

Fíjate en estos errores:

• Dos cabeceras HSTS. Si la CDN y el servidor de origen añaden una cada uno, el RFC 6797 indica que el navegador procese solo la primera, y la revisión de hstspreload.org lo marca como error («Multiple HSTS headers»). Decide qué capa es la responsable de la cabecera.
• Una directiva mal escrita. Los navegadores descartan sin avisar las directivas que no reconocen, así que un includeSubdomain sin la s final deja los subdominios sin cubrir sin que nadie lo note.
• Respuestas sin cabecera. La página de inicio la tiene, pero no las páginas de error, la API o los archivos estáticos que sirve otra capa.

En Chrome DevTools, abre el panel Network y escribe http://example.com/ en la barra de direcciones cuando el navegador ya haya guardado la política. La primera entrada muestra 307 Internal Redirect con Non-Authoritative-Reason: HSTS: el navegador ha pasado a HTTPS por su cuenta, antes de que ninguna petición llegara al servidor. La referencia de MDN recoge la sintaxis de la cabecera.

7. Cómo comprobar tu estado en la lista de precarga

• hstspreload.org. Escribe el dominio en el formulario. Te dice si está precargado, pendiente o fuera de la lista, junto con los errores y avisos respecto a los requisitos actuales. Un dominio pendiente todavía no está protegido: aún tiene que llegar en una versión del navegador.
• chrome://net-internals/#hsts. En Chrome, introduce el dominio en «Query HSTS/PKP domain». Los campos que empiezan por static_ vienen de la lista integrada en esa versión del navegador; los que empiezan por dynamic_, de las cabeceras que el navegador ha recibido. «Delete domain security policies» solo borra la parte dinámica, así que una entrada precargada sigue ahí hasta que una actualización del navegador la quite.
• Otros navegadores. Firefox, Safari y Edge distribuyen sus propias copias, derivadas de la lista de Chrome, con su propio calendario, de modo que una alta o una baja puede llegarles en momentos distintos.

Repite la comprobación después de cualquier cambio en el DNS, la CDN o los certificados. hstspreload.org advierte de que los dominios que dejen de reunir los requisitos podrían retirarse automáticamente en el futuro.

8. Salir de la lista: pasos y plazos de la retirada

1. Sigue sirviendo HTTPS con un certificado válido en el dominio base; el formulario de retirada lo comprueba.
2. Envía una cabecera HSTS sin preload. hstspreload.org la trata como la solicitud de retirada. Conserva includeSubDomains y un max-age largo si quieres seguir con HSTS, o envía max-age=0 para desactivarlo del todo.
3. Envía el dominio en el formulario de retirada.
4. Mientras esperas, dale un certificado válido al subdominio que motivó la decisión o trasládalo a otro dominio: la retirada puede tardar de 6 a 12 semanas en llegar a la mayoría de los usuarios de Chrome, y más en otros navegadores.
5. No vuelvas a enviar preload salvo que quieras regresar a la lista.

max-age=0 solo funciona por HTTPS y solo para los visitantes que vuelven y lo reciben. Planifica pensando en el caso más lento: un navegador desactualizado que aún tenga la entrada integrada, o una política guardada de dos años, puede seguir forzando HTTPS mucho después de que hayas cambiado de planes.

9. Qué muestra el snapshot gratuito de Sitelemetry

El snapshot gratuito de Sitelemetry (Launch Readiness Snapshot) ejecuta ocho comprobaciones pasivas sobre un dominio público, sin registro, y devuelve una puntuación con el resultado de cada comprobación. Dos de ellas tienen que ver con HSTS:

• La comprobación de cabeceras de seguridad HTTP lee la página de inicio del dominio que escribes, tras seguir hasta cinco redirecciones. Valora como media la ausencia de Strict-Transport-Security en un destino HTTPS y muestra el valor observado.
• La comprobación de redirección HTTPS marca como baja un max-age inferior a 180 días (15.552.000 segundos) cuando escribes solo el dominio o una dirección https://. Durante las etapas 1 a 3 del plan, ese resultado es lo esperable.

No comprueba includeSubDomains, la directiva preload, tus subdominios ni tu estado en la lista; para eso usa hstspreload.org y los comandos curl de arriba. Si quieres ver primero el resultado de las cabeceras, usa el comprobador gratuito de cabeceras de seguridad, que ejecuta el mismo snapshot. Para la parte del certificado, lee la guía de certificados TLS y HSTS, y el checklist de seguridad para lanzar una web sitúa HSTS junto a las redirecciones, el DNS y el resto de comprobaciones previas al lanzamiento.