HSTS preload

Qué comprueba esta verificación

Busca tu dominio en la lista HSTS preload de Chromium — una lista estática de dominios solo-HTTPS compilada directamente en Chrome, Firefox, Safari, Edge y Brave. Para los dominios listados, los navegadores rechazan conexiones HTTP en claro desde la primerísima petición, antes incluso de haber visto cabecera alguna.

La comprobación devuelve uno de: preloaded, pending submission, not preloaded o removal in progress.

Por qué importa

HSTS cierra la ventana del downgrade attack — pero solo después de que un navegador haya visto la cabecera una vez. La primera visita que un usuario hace a tu dominio sigue siendo en texto plano. Sobre Wi-Fi hostil o con un router comprometido, un atacante puede interceptar esa primera petición, quitar la redirección a HTTPS y servir una versión maliciosa de tu sitio antes de que HSTS llegue a activarse.

Preload elimina esa ventana. El navegador sabe que tu dominio es solo-HTTPS antes de que el usuario escriba la URL. Incluso en una instalación recién hecha sin historial, la primera petición va cifrada.

Esto importa sobre todo para: banca, salud, cuentas con credenciales valiosas, flujos de pago y cualquier sitio donde la primera visita pueda comprometer al usuario. Para un sitio de marketing sin auth, preload es una señal agradable de madurez operativa pero no es crítico.

El trade-off: el preload es difícil de revertir. La eliminación suele tardar 6–12 semanas vía canal estable de Chrome, y los usuarios en versiones antiguas siguen bloqueados aún más tiempo. Envíalo solo cuando tengas la certeza de que tu dominio hablará HTTPS para siempre.

Cómo arreglarlo

1. Verifica los prerrequisitos antes de enviar.

Según la política de hstspreload.org, tu sitio debe:

• Servir un certificado HTTPS válido en el dominio apex y en www.
• Redirigir HTTP → HTTPS en el mismo host (ver redirigir HTTP a HTTPS).
• Enviar una cabecera HSTS en cada respuesta HTTPS con:
  • max-age ≥ 31536000 (un año)
  • includeSubDomains
  • preload
• Servir todos los subdominios también por HTTPS — includeSubDomains es literal.

La cabecera lista para producción:

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

Dos años es el valor convencional una vez que tienes confianza.

2. Configura la cabecera.

nginx:

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

Apache:

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

Cloudflare: SSL/TLS → Edge Certificates → HSTS → fija max-age a 12+ meses, activa Include subdomains, activa Preload, activa No-Sniff Header.

3. Verifica antes de enviar.

curl -sI https://yourdomain.com | grep -i strict-transport-security
curl -sI https://www.yourdomain.com | grep -i strict-transport-security
curl -sI https://anysubdomain.yourdomain.com | grep -i strict-transport-security

Las tres deberían devolver la cabecera con las tres directivas. Si un subdominio no tiene la cabecera o sirve no-HTTPS, la solicitud será rechazada.

4. Envíalo en hstspreload.org.

Introduce el dominio en hstspreload.org, acepta los avisos, pulsa Submit. El formulario corre la misma verificación que la comprobación manual de arriba. Los dominios aprobados aterrizan en la siguiente release de Chrome (6–12 semanas hasta estable). Firefox, Safari y Edge tiran de la lista de Chromium a su propio ritmo.

5. Planifica el peor caso antes de enviar.

Repasa estos modos de fallo y confirma que cada uno está OK:

• El cert caduca sin que nadie esté pendiente. Los usuarios reciben un error duro sin fallback a HTTP. Automatiza la renovación (Let’s Encrypt + timer de certbot o el cert gestionado de tu proveedor cloud).
• Un subdominio necesita HTTP (dispositivo legacy, IoT, herramienta interna). No va a funcionar. Estás bloqueado en HTTPS en todo el eTLD+1.
• Adquisición / venta del dominio. El nuevo dueño hereda la entrada de preload hasta que se complete la eliminación. Los compradores deberían revisar la lista de preload antes de comprar.
• Dominio solo interno enviado por accidente. La eliminación tarda meses. Envía únicamente dominios públicos de producción.

6. Eliminación, si alguna vez la necesitas.

Envía una solicitud de eliminación en hstspreload.org. El dominio sale en la siguiente actualización de Chromium (~6 semanas). Las instalaciones antiguas siguen bloqueadas todo el tiempo que diga su max-age, y los usuarios que no actualicen Chrome pueden quedarse atrapados un año o más. Baja el max-age a un valor pequeño (por ejemplo 300) con bastante antelación para limitar el bloqueo residual.

Preguntas frecuentes

¿Necesito preload si ya tengo HSTS?

Para la mayoría de sitios de marketing, no. El HSTS normal protege a todo el mundo después de su primera visita, lo que es suficiente cuando no hay auth ni pagos. Preload importa cuando (a) manejas credenciales, dinero o PHI, (b) puedes garantizar HTTPS para siempre y (c) ya llevas unos meses con HSTS sin incidencias.

¿Cuánto tarda en aparecer de verdad en Chrome?

Desde el envío hasta la primera release estable de Chrome: típicamente 6–12 semanas. El formulario dirá “pending” hasta la siguiente compilación de la lista y luego “pending preload” mientras pasa por los canales de Chrome (canary → dev → beta → stable). Firefox, Safari y Edge tiran de la lista de Chromium con sus propios ciclos de actualización — calcula 3–6 meses para una cobertura amplia.

¿Puedo preload solo un subdominio, como app.example.com?

Sí, pero solo si el eTLD+1 padre no está ya en preload. Envía app.example.com directamente. Aplican los mismos prerrequisitos (cabecera HSTS con la directiva preload, HTTPS en todo ese hostname). Es el enfoque correcto cuando controlas un subdominio pero no puedes comprometer a toda la organización a HTTPS-para-siempre.