HSTS: la guía completa para activar Strict-Transport-Security y la preload list

⚡TL;DR

• HSTS (RFC 6797) indica al navegador que solo contacte un dominio por HTTPS durante el tiempo definido por max-age, neutralizando los ataques sslstrip y el downgrade de protocolo
• La cabecera se compone de tres directivas: max-age (obligatoria), includeSubDomains (cubre los subdominios) y preload (opt-in a la lista embebida en Chrome y derivados)
• Para ser elegible para la preload list, hace falta max-age mayor o igual a 31 536 000, includeSubDomains, preload y una redirección HTTP a HTTPS en el dominio apex
• La preload list es casi irreversible: una retirada lleva varios meses y solo afecta a las versiones futuras de los navegadores
• En abril de 2026, alrededor de 120 000 dominios figuran en la preload list de Chrome y solo el 35,7 % de los sitios con HSTS han activado la directiva preload

En 2009, Moxie Marlinspike presentó sslstrip en Black Hat DC. La herramienta intercepta el tráfico HTTP de un usuario en una red pública, sustituye al vuelo cada enlace y redirección HTTPS por su equivalente HTTP, y luego retransmite las peticiones en claro. El usuario cree estar protegido por TLS, cuando en realidad todo su tráfico, incluidos los cookies de sesión y las contraseñas, sale en claro por el cable. En esa misma época, la extensión de Firefox Firesheep (octubre de 2010) popularizó el robo de sesiones en Facebook y Twitter desde cualquier hotspot Wi-Fi abierto.

HSTS (HTTP Strict Transport Security) es la respuesta a estos ataques. Estandarizado por la RFC 6797 en noviembre de 2012, permite a un servidor HTTPS indicar al navegador que, durante un tiempo definido, solo debe comunicarse con el dominio por HTTPS. Cuando la cabecera se recibe y memoriza, el navegador convierte localmente toda petición http:// en https:// antes incluso de enviar el más mínimo paquete por la red. La ventana de interceptación durante la primera redirección desaparece.

En abril de 2026, según los estudios de adopción de AppSecSanta, solo el 35,7 % de los sitios que envían una cabecera HSTS usan la directiva preload. La Chrome HSTS Preload List contiene unos 120 000 dominios, muy lejos del parque HTTPS mundial. HSTS sigue siendo, por tanto, infrautilizado, a menudo mal configurado, y a veces activado con efectos colaterales inesperados sobre subdominios internos en HTTP.

Esta guía cubre tres objetivos: comprender con precisión qué hace HSTS (y qué no hace), configurar la cabecera en los cinco stacks web más habituales, y enviar correctamente un dominio a la preload list sin romper la infraestructura. Está dirigida a DevOps, SRE, administradores de sistemas y CTO de pymes que preparan una auditoría de seguridad o un envío a preload.

¿Qué es HSTS?

HSTS es una cabecera de respuesta HTTP enviada por un servidor HTTPS válido. Anuncia al agente de usuario (navegador, biblioteca HTTP, agente automatizado compatible con la RFC 6797) que el dominio debe contactarse exclusivamente por HTTPS durante el tiempo indicado por la directiva max-age.

Una vez recibida la cabecera sobre una conexión TLS válida, el navegador registra localmente lo que se denomina un "Known HSTS Host". Para cualquier petición posterior hacia ese dominio, incluidas las disparadas por un clic en un enlace http://, un marcador guardado o una redirección 301 servida por otro servidor, el navegador reescribe la URL como https:// antes del envío. La conversión se hace en memoria, en el lado cliente, sin petición de red intermedia.

Tres elementos hacen que HSTS sea eficaz:

1. La conversión es local. Nunca se emite ninguna petición HTTP hacia un dominio conocido en HSTS. Un atacante en posición de man-in-the-middle solo ve TLS.
2. Los errores de certificado son fatales. En un dominio en HSTS, el navegador suprime el botón "Continuar de todos modos" que el usuario podría pulsar ante un error TLS. Un certificado autofirmado inyectado por un atacante provoca un bloqueo, no una advertencia.
3. El TTL del lado del navegador se prolonga en cada visita. Mientras el usuario visite el sitio con regularidad, max-age se refresca en cada respuesta, lo que impide la expiración.

La cabecera está estandarizada y soportada por todos los navegadores principales desde 2011. Chromium 4.0.211, Firefox 4.0 (agosto de 2010), Opera 12, Safari en OS X 10.7.3, Edge desde sus inicios e Internet Explorer 11 la implementan. En abril de 2026, la compatibilidad es universal: el 98 % del tráfico web mundial pasa por un navegador compatible con HSTS.

El problema que resuelve HSTS

sslstrip y el downgrade de protocolo

Sin HSTS, la protección HTTPS de un sitio presenta un eslabón débil: la primera petición. Cuando un usuario teclea captaindns.com en la barra de direcciones, el navegador emite por defecto una petición en HTTP al puerto 80. El servidor responde con una redirección 301 hacia https://captaindns.com. Esa primera petición sale en claro. Un atacante en la red local puede interceptarla.

El ataque sslstrip funciona así: el atacante se sitúa entre el usuario y la pasarela de red (ARP spoofing, rogue access point, compromiso DHCP). Intercepta la petición HTTP inicial, la retransmite hacia el servidor legítimo en HTTPS, recibe la respuesta, sustituye todos los https:// por http:// en el HTML, las cabeceras y los cookies, y luego la devuelve en claro al usuario. Desde el punto de vista del navegador, todo parece normal: una página HTTP clásica, sin error. El usuario introduce su contraseña, que viaja en claro hasta el atacante y luego se retransmite cifrada hacia el servidor.

HSTS neutraliza sslstrip en las visitas posteriores. Tras la primera petición HTTPS exitosa, el navegador memoriza la cabecera. La segunda visita, aunque empiece con un clic en un enlace http:// o una redirección desde un dominio de terceros, nunca sale en HTTP. El navegador convierte localmente la URL antes del DNS, antes del connect(), antes de cualquier tráfico de red.

El límite sigue siendo la primerísima visita. Un navegador que nunca ha recibido la cabecera HSTS para un dominio es vulnerable a sslstrip en su primera petición. Eso es precisamente lo que corrige la preload list: la lista embebida en Chrome permite al navegador conocer los dominios en HSTS desde su salida de fábrica, sin esperar a una primera conexión.

Robo de cookies y Firesheep

Firesheep, publicada en octubre de 2010, demostró a gran escala lo trivial que era el robo de sesión en redes públicas. La extensión esnifaba los cookies de sesión de Facebook, Twitter, Flickr y muchos otros sitios que aún servían a sus usuarios autenticados por HTTP (o que pasaban a HTTPS solo para la página de login y volvían a bajar a HTTP). En el Wi-Fi de una cafetería, hacer clic sobre un usuario en la interfaz de Firesheep permitía acceder a su cuenta con un solo gesto.

HSTS refuerza la protección de los cookies de dos formas. Por un lado, al forzar HTTPS, elimina la fuga del cookie por una conexión sin cifrar. Por otro, combinado con el atributo Secure en el cookie (que impide su envío por HTTP) y HttpOnly (que bloquea el acceso desde JavaScript), cierra los tres vectores principales de robo de sesión por red.

Con la directiva includeSubDomains, HSTS también protege los cookies definidos sin especificar un dominio explícito. Un cookie creado por www.captaindns.com sin Secure podría, sin HSTS, enviarse a api.captaindns.com por HTTP si se cargara allí un subrecurso en claro. Con includeSubDomains, todas las peticiones hacia cualquier subdominio se fuerzan a HTTPS, y el cookie permanece cifrado.

Bootstrap MITM y la preload list

La RFC 6797 §14.6 reconoce explícitamente la vulnerabilidad del "bootstrap MITM": un usuario que visita un dominio por primera vez aún no ha recibido la cabecera HSTS, y su petición HTTP inicial sigue siendo interceptable. Es la famosa ventana de la primera visita.

La preload list de Chromium resuelve este problema al embeber en el código fuente del navegador la lista de dominios en HSTS. Chrome, Firefox, Safari y Edge importan esta lista en cada actualización. Para un dominio presente, el navegador sabe que debe usar HTTPS desde la primerísima petición, sin haber visitado siquiera el sitio. La ventana de bootstrap desaparece.

La inscripción es gratuita pero exigente: max-age mayor o igual a 1 año, includeSubDomains, preload, redirección HTTP a HTTPS en el dominio apex. Una vez inscrito, la retirada lleva varios meses, ya que hay que esperar a que todas las versiones desplegadas de los navegadores importen la nueva lista. Algunos usuarios con versiones antiguas seguirán forzando HTTPS en tu dominio durante años.

Anatomía de la cabecera Strict-Transport-Security

La sintaxis está definida por la RFC 6797 §6.1. La cabecera se compone de una directiva obligatoria (max-age) y de dos directivas opcionales (includeSubDomains, preload), separadas por punto y coma.

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

Las directivas son insensibles a mayúsculas y minúsculas (IncludeSubDomains es válido pero no canónico). Una directiva desconocida es silenciosamente ignorada por los navegadores conformes. Si la sintaxis completa no es válida, la cabecera entera se rechaza: una sola errata puede desactivar tu protección sin alerta visible. De ahí la importancia de probar la configuración con una herramienta dedicada antes de desplegar en producción.

Reglas de validez

Varias reglas estrictas de la RFC 6797 influyen en el despliegue:

• HTTPS obligatorio. Una cabecera HSTS recibida por HTTP se ignora (§8.1). Esta regla es crucial: impide que un atacante man-in-the-middle inyecte un max-age=0 por HTTP para desactivar HSTS en una víctima.
• Certificado válido obligatorio. La cabecera solo se tiene en cuenta si la conexión TLS se ha establecido sin error ni advertencia (§8.1). Un certificado caducado, un nombre de dominio incorrecto, una cadena incompleta: todo eso impide la memorización.
• Solo la primera ocurrencia. Si se envían varias cabeceras HSTS en la misma respuesta, solo se procesa la primera (§8.1). Cuidado con los middlewares, CDN y reverse proxies que apilan sus propias cabeceras.
• Sin direcciones IP. HSTS solo se aplica a nombres de dominio. Un sitio accesible vía https://192.168.1.1 no se ve afectado (§8.3).
• Todos los puertos. HSTS cubre el dominio en todos los puertos. Un puerto 80 se convierte automáticamente en 443, pero un puerto personalizado se mantiene en su número.

Tres ejemplos canónicos

# Mínimo viable: 1 año, sin subdominios
Strict-Transport-Security: max-age=31536000

# Recomendación OWASP: 1 año con subdominios
Strict-Transport-Security: max-age=31536000; includeSubDomains

# Elegible para preload list: 2 años con subdominios y opt-in preload
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

La tercera línea es la configuración objetivo para todo sitio público que desee una protección máxima. La detallamos sección por sección.

max-age: la duración de la política

max-age es la única directiva obligatoria. Expresa en segundos el tiempo durante el cual el navegador debe considerar el dominio como "Known HSTS Host". Algunos valores típicos:

Valor	Duración	Uso
0	Inmediato	Eliminación de la política HSTS
300	5 minutos	Prueba inicial, rollout prudente
3600	1 hora	Staging, validación corta
86 400	1 día	Rollout progresivo, día 1
604 800	1 semana	Rollout progresivo, semana 1
31 536 000	1 año	Umbral mínimo de la preload list (desde el 11 de octubre de 2017)
63 072 000	2 años	Recomendación habitual para preload

El contador se reinicia con cada respuesta HTTPS que contenga la cabecera. En concreto, si tu sitio envía max-age=31536000 y un usuario visita una página al mes, la política nunca se extingue mientras vuelva dentro del año. A la inversa, si retiras bruscamente la cabecera, los navegadores que hayan recibido la política seguirán forzando HTTPS hasta la expiración local. Es un efecto trinquete: HSTS solo es fácil de activar en un sentido.

Rollout progresivo recomendado

OWASP y cio.gov recomiendan una activación progresiva para evitar quedarse atrapado con una política de un año en un sitio aún en despliegue. Un plan tipo:

1. Día 0: max-age=300. 5 minutos. Verifica que la cadena HTTPS funciona, que la redirección HTTP a HTTPS es estable, que todos los contenidos internos se sirven por HTTPS. Una retirada es trivial, la política caduca en 5 minutos.
2. Día 1: max-age=86 400. 1 día. Observa los errores TLS reportados por tu sistema de monitorización, tu WAF y tus logs de aplicación durante 24 horas. Vigila especialmente las redirecciones rotas hacia recursos internos.
3. Día 7: max-age=604 800. 1 semana. Si la tasa de errores TLS se mantiene estable, pasa a una semana. Esta etapa valida que todos los subdominios activos son accesibles por HTTPS.
4. Día 14: max-age=31 536 000. 1 año. La política es estable, los usuarios están protegidos. Si apuntas a la preload list, puedes activar includeSubDomains y preload en esta etapa tras una auditoría.

Este ritmo permite dar marcha atrás en cada paso. Pasar directamente a 1 año sin pruebas intermedias es el error más frecuente: si un solo subdominio olvidado se rompe tras activar includeSubDomains, te quedas bloqueado durante un año en el lado del navegador.

Desactivación mediante max-age=0

La RFC 6797 §6.1.1 precisa que un valor de 0 indica al navegador que elimine la política en caché. Es la única forma de retirar HSTS limpiamente: servir durante el tiempo anterior una cabecera con max-age=0, esperar a que los navegadores reciban esta actualización, y luego retirar completamente la cabecera. Atención, esta desactivación solo es efectiva por HTTPS (§8.1). Un max-age=0 servido por HTTP se ignora.

includeSubDomains: extender la protección

La directiva includeSubDomains extiende la política HSTS a todos los subdominios del nombre de host que la ha enviado. Enviada desde captaindns.com, cubre www.captaindns.com, api.captaindns.com, blog.captaindns.com, así como todos los subsubdominios (staging.api.captaindns.com, etc.).

La RFC 6797 §8.2 precisa que el matching se hace etiqueta por etiqueta, de derecha a izquierda, insensible a mayúsculas. Una política HSTS declarada en captaindns.com cubre, por tanto, toda la jerarquía DNS por debajo. A la inversa, una política declarada en www.captaindns.com no cubre ni api.captaindns.com ni captaindns.com, ya que la raíz no es un subdominio de www.

Por qué es crítico para los cookies

Sin includeSubDomains, un atacante puede sortear HSTS forzando una petición HTTP hacia un subdominio. Escenario clásico:

1. El usuario se conecta a https://captaindns.com protegido por HSTS, recibe un cookie de sesión sin atributo Secure.
2. El atacante inyecta una imagen <img src="http://blog.captaindns.com/pixel.png"> en una página visitada por la víctima (vía XSS, un foro, o un man-in-the-middle en otro sitio).
3. El navegador emite la petición por HTTP hacia blog.captaindns.com y le adjunta automáticamente el cookie del dominio padre (porque los cookies se propagan a los subdominios).
4. El atacante, situado en la red, captura el cookie en claro.

Con includeSubDomains, la petición hacia blog.captaindns.com se convierte en HTTPS antes del envío. El cookie permanece cifrado en el cable. Por esta razón, la OWASP Cheat Sheet recomienda sistemáticamente includeSubDomains siempre que sea posible.

Las trampas a evitar

includeSubDomains tiene un efecto colateral radical: todos los subdominios, incluidos los que no son públicos, deben servir HTTPS. Estas son las trampas más frecuentes, documentadas por las comunidades DevOps:

• Herramientas internas en HTTP. Un grafana.interno.captaindns.com servido por HTTP en la red privada se volverá inaccesible para los usuarios que ya hayan memorizado la política HSTS de captaindns.com.
• Entornos de staging. Un staging.captaindns.com con un certificado autofirmado provoca errores TLS fatales para los equipos que se conectan desde puestos que han visitado producción.
• Subdominios históricos. Un antiguo mail.captaindns.com servido por un proveedor externo en HTTP corre el riesgo de romper los enlaces de correos antiguos.
• Subdominios de terceros. Un subdominio delegado a un proveedor SaaS (support.captaindns.com apuntando a Zendesk, por ejemplo) debe ofrecer HTTPS con un certificado válido para el nombre delegado.

Antes de activar includeSubDomains, haz un inventario exhaustivo. Los equipos más experimentados pasan por una fase de "shadow mode": activar HSTS sin includeSubDomains durante varias semanas, correlacionar con los logs DNS para identificar los subdominios activos, y conmutar solo tras una auditoría completa.

Alternativa: HSTS a nivel de subdominio

Si algunos subdominios no pueden conmutarse a HTTPS (legacy, contrato externo), una alternativa es declarar HSTS individualmente en cada subdominio que lo permita, sin includeSubDomains a nivel de la raíz. Es más verboso pero evita romper los subdominios en HTTP. El coste: cada subdominio debe mantener su propia política, y no podrás ser elegible para la preload list sin includeSubDomains en el apex.

preload: la lista embebida

La directiva preload es un opt-in mediante el cual el propietario del dominio declara su intención de figurar en la Chrome HSTS Preload List. Sin esta directiva, el dominio no será aceptado al envío, aunque cumpla todos los demás criterios.

Las cuatro condiciones de elegibilidad

hstspreload.org exige, desde el 11 de octubre de 2017, que la cabecera servida por el dominio apex respete cuatro condiciones:

1. max-age mayor o igual a 31 536 000 (1 año). Un max-age más corto se rechaza.
2. includeSubDomains presente. La preload list cubre siempre el árbol DNS completo.
3. preload presente. Declaración de intención explícita.
4. Redirección HTTP a HTTPS en el dominio apex. Si el servidor acepta conexiones en el puerto 80, debe devolver un 301 hacia HTTPS. La redirección también debe servir la cabecera HSTS.

También se exigen un certificado TLS válido y la capacidad de servir todos los subdominios (incluido www) por HTTPS. La herramienta de envío prueba automáticamente estas condiciones antes de aceptar la solicitud.

El proceso de envío

Una vez cumplidas las condiciones, el envío se realiza en tres pasos:

1. Prueba automática. En hstspreload.org, introduce tu dominio. El servicio prueba la cabecera HSTS, la redirección HTTP a HTTPS, la disponibilidad HTTPS de los subdominios www. Los errores se detallan.
2. Envío. Si la prueba pasa, aparece disponible un botón "Submit to the HSTS preload list". Confirma tras leer las advertencias sobre la irreversibilidad.
3. Integración. El dominio pasa al estado pending. Se integra en la lista fuente de Chromium, se propaga a Firefox, Safari, Edge. La propagación completa lleva entre 6 y 12 semanas, según los ciclos de release de los navegadores.

Puedes verificar el estado en cualquier momento mediante curl https://hstspreload.org/api/v2/status?domain=captaindns.com.

La irreversibilidad

Es el punto más importante a comprender. Una vez en la preload list, una retirada lleva varios meses y solo afecta a las versiones futuras de los navegadores. Los usuarios con una versión antigua seguirán forzando HTTPS en tu dominio durante años. Es especialmente molesto en tres casos:

• Venta de dominio. Si cedes captaindns.com a un tercero que desea utilizarlo en HTTP, tu opt-in se lo impedirá.
• Desmantelamiento de infraestructura. Si paras un servicio y el dominio se reutiliza para otra cosa, HSTS permanece en caché.
• Rollback de emergencia. Si un ataque o un incidente corrompe tu cadena TLS, no puedes desactivar HTTPS de urgencia.

La página hstspreload.org/removal/ documenta el procedimiento de retirada. Advierte explícitamente de que el proceso puede llevar varios meses y que algunos usuarios nunca verán la retirada.

Adopción real en abril de 2026

El estudio de APNIC 2023 y los datos de 2026 muestran que la adopción sigue siendo baja a pesar de los beneficios:

Estadística	Valor
Dominios en la preload list	~120 000
Tamaño del archivo embebido	~18 MB
Sitios con HSTS que activan preload	35,7 %
Top 20 mundial en la preload list	8 de 20
Adopción finanzas / banca	Muy baja

Google, GitHub, Twitter, Facebook y PayPal figuran en la lista. En cambio, la mitad de los 20 sitios más grandes del mundo no tienen HSTS en su dominio apex. Los sectores regulados (finanzas, salud) van con retraso, a menudo por conservadurismo respecto a la reversibilidad.

Guía paso a paso: activar HSTS por stack

Cubrimos aquí los cinco entornos más desplegados en 2026. Para cada stack, la configuración da primero el mínimo viable, luego la versión elegible para preload.

Nginx

En Nginx, la cabecera HSTS se emite mediante la directiva add_header en el bloque server que escucha en el puerto 443. El parámetro always es esencial: sin él, Nginx solo añade la cabecera en las respuestas 2xx y 3xx, y la omite en las 4xx y 5xx. Un atacante podría entonces forzar un error 404 para sortear la protección.

Configuración mínima:

server {
    listen 443 ssl http2;
    server_name captaindns.com;

    ssl_certificate /etc/letsencrypt/live/captaindns.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/captaindns.com/privkey.pem;

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

    # resto de la configuración
}

Configuración elegible para preload:

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

Cuidado con los bloques anidados. Nginx aplica add_header únicamente al nivel más específico que contenga un add_header. Si declaras HSTS a nivel server y luego vuelves a declarar otro add_header en un bloque location, el HSTS del nivel server desaparece en esa location. La solución: repetir la directiva HSTS en cada location o usar more_set_headers del módulo nginx_headers_more.

El bloque de escucha en el puerto 80 debe efectuar la redirección 301 hacia HTTPS:

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

Nunca añadas la cabecera HSTS en este bloque del puerto 80. Los navegadores la ignoran (RFC 6797 §8.1), pero su presencia confunde las auditorías e indica una configuración aproximativa.

Apache HTTPD

Apache gestiona HSTS mediante el módulo mod_headers. En Debian y derivados, actívalo con sudo a2enmod headers y luego sudo systemctl reload apache2. La directiva Header always set escribe la cabecera en todas las respuestas, incluidos los errores.

Configuración mínima en /etc/apache2/sites-available/captaindns.com.conf o en un .htaccess en la raíz del sitio:

<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=31536000"
</IfModule>

Configuración elegible para preload:

<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
</IfModule>

Como en Nginx, la cabecera debe colocarse únicamente en el VirtualHost que escucha en el puerto 443. El VirtualHost del puerto 80 debe contener una redirección hacia HTTPS, típicamente vía mod_rewrite o la directiva Redirect permanent:

<VirtualHost *:80>
    ServerName captaindns.com
    ServerAlias www.captaindns.com
    Redirect permanent / https://captaindns.com/
</VirtualHost>

La colocación en .htaccess también funciona, lo que es útil para los hostings compartidos. Hay que verificar, sin embargo, que la directiva AllowOverride autorice Headers en la configuración del servidor.

Cloudflare

Cloudflare ofrece una gestión nativa de HSTS en su panel de control. Dos ventajas: ninguna modificación de la configuración del servidor, y Cloudflare sirve la cabecera en todas las respuestas que atraviesan el CDN, incluidas las páginas de error gestionadas en el edge.

Para activar HSTS en Cloudflare:

1. Conéctate al panel de Cloudflare y selecciona el dominio.
2. Ve a SSL/TLS y luego a Edge Certificates.
3. Desplázate hasta HTTP Strict Transport Security (HSTS) y haz clic en Enable HSTS.
4. Lee la advertencia, marca "I understand" y luego Next.
5. Configura las opciones:
   • Max Age: elige 12 meses como mínimo (18 o 24 meses para preload).
   • Apply HSTS policy to subdomains: activa includeSubDomains.
   • Preload: activa la directiva preload.
   • No-Sniff Header: añade X-Content-Type-Options: nosniff (recomendado).
6. Haz clic en Save.

Cloudflare añade inmediatamente la cabecera a todas las respuestas. Verifica con curl -I https://captaindns.com que la cabecera está presente.

Atención: Cloudflare sirve HSTS incluso si tu origen está en HTTP detrás de Cloudflare. Es una trampa clásica: puedes hacer que tu sitio sea elegible para la preload list aunque el origen sea técnicamente inseguro. Si un día cambias de CDN o pasas a DNS Only, los visitantes caerán en un origen HTTP bloqueado por HSTS. Antes de activar preload vía Cloudflare, asegúrate de que tu origen está realmente en HTTPS.

AWS CloudFront

CloudFront gestiona HSTS mediante las Response Headers Policies, introducidas en 2021. Puedes utilizar una policy gestionada por AWS (Managed-SecurityHeadersPolicy) o crear una policy personalizada para un control fino.

Vía la consola de AWS:

1. CloudFront → Policies → Response headers → Create response headers policy.
2. Sección Strict-Transport-Security: activa la casilla.
3. Rellena:
   • Max-age (seconds): 63072000 para preload, 31536000 en caso contrario.
   • Include subdomains: marca para preload.
   • Preload: marca para preload.
   • Override origin: marca para que CloudFront sobrescriba la cabecera que pueda enviar el origen (recomendado).
4. Crea la policy y luego adjúntala a tu distribución de CloudFront en la pestaña Behaviors.

Vía Terraform:

resource "aws_cloudfront_response_headers_policy" "security" {
  name = "captaindns-security-headers"

  security_headers_config {
    strict_transport_security {
      access_control_max_age_sec = 63072000
      include_subdomains         = true
      preload                    = true
      override                   = true
    }
  }
}

resource "aws_cloudfront_distribution" "captaindns" {
  # ...
  default_cache_behavior {
    # ...
    response_headers_policy_id = aws_cloudfront_response_headers_policy.security.id
  }
}

La ventaja de una Response Headers Policy frente a una CloudFront Function es el coste: gratis, sin facturación por petición.

Caddy

Caddy se distingue: no proporciona HSTS por defecto, deliberadamente. Matt Holt, su creador, considera que una activación automática sería peligrosa para los usuarios que pudieran querer retirar HTTPS más adelante.

La activación manual es sencilla, mediante la directiva header en el Caddyfile:

captaindns.com {
    tls admin@captaindns.com

    header {
        Strict-Transport-Security "max-age=31536000"
    }

    # resto de la configuración
}

Para la versión preload:

captaindns.com {
    tls admin@captaindns.com

    header {
        Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
    }
}

Caddy gestiona automáticamente la redirección HTTP a HTTPS, y renueva sus certificados Let's Encrypt en segundo plano. Por tanto, puedes activar HSTS con confianza desde el día 1, ya que Caddy garantiza la disponibilidad de HTTPS a largo plazo.

Para un reverse proxy, el patrón es idéntico, pero coloca la directiva header en el bloque que sirve el front:

captaindns.com {
    header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
    reverse_proxy localhost:3000
}

Cómo proceder al preloading HSTS

Una vez la cabecera HSTS sea estable en tu dominio apex con las tres directivas, puedes enviar a la preload list. No precipites este paso: la decisión es casi irreversible.

Checklist antes del envío

Recorre esta lista. Cada casilla debe estar marcada.

• Todos los subdominios públicos (www, api, mail, blog, shop) sirven HTTPS con un certificado válido.
• Todos los subdominios internos (staging, admin, monitoring, ci) sirven HTTPS o están cerrados al exterior.
• El dominio apex sirve https:// con un certificado cuyo SAN cubre realmente el apex.
• La redirección HTTP a HTTPS en el dominio apex devuelve un 301 (no un 302).
• La cabecera HSTS en el apex contiene max-age=31536000 (o más), includeSubDomains y preload.
• La cadena TLS es completa (ningún certificado intermedio falta).
• No tienes ningún subdominio gestionado por un tercero que pudiera no soportar HTTPS (por ejemplo, un blog antiguo en HTTP en un hosting legacy).
• Has vivido al menos 30 días con la configuración final para capturar los casos límite.

Pasa la prueba automática en hstspreload.org. Si aparece un indicador rojo, corrige antes de enviar. Errores típicos: certificado autofirmado en www, redirección 302 en lugar de 301, ausencia de cabecera HSTS en la respuesta 301 del HTTP.

Enviar el dominio

Una vez la prueba esté en verde, haz clic en el botón de envío, introduce tu dirección de correo y confirma. El dominio pasa al estado pending. En 3 o 4 semanas, se integra en el código fuente de Chromium. En 6 a 12 semanas, está presente en las versiones estables de Chrome, Firefox, Safari y Edge.

Puedes seguir el estado:

curl "https://hstspreload.org/api/v2/status?domain=captaindns.com"

Estados posibles: unknown (desconocido), pending (pendiente), preloaded (integrado), rejected (rechazado, ver detalles).

Mantener la política tras el envío

Conserva la cabecera HSTS con las tres directivas de forma permanente. Algunas empresas retiran preload tras el envío creyendo que ya está hecho: es un error. La presencia continuada de la directiva se verifica en las auditorías periódicas de la preload list por parte del equipo de Chromium, y su ausencia puede provocar una retirada.

Retirar un dominio (procedimiento largo)

Si debes retirar tu dominio de la preload list:

1. Ve a hstspreload.org/removal/.
2. Aporta los motivos (venta de dominio, migración de infraestructura, etc.).
3. Sirve max-age=0 en tu dominio durante el período de retirada.
4. Espera de 4 a 12 semanas para la integración en Chromium.
5. Espera entre 6 y 12 meses adicionales para que la mayoría de los usuarios hayan actualizado su navegador.

Durante este período, tu dominio sigue forzado a HTTPS en la mayoría de los navegadores. Prepara el procedimiento antes de no poder seguir sirviendo TLS.

Errores frecuentes y antipatrones

Activar HSTS sin haber probado la cadena HTTPS

Es el error más costoso. Activar max-age=31536000 antes de haber validado que todos los endpoints sirven correctamente HTTPS bloquea a los usuarios durante un año. Empieza siempre con max-age=300 y avanza por etapas.

Olvidar always en Nginx

Sin always, add_header solo se emite en las respuestas 2xx/3xx. En una página de error 500 o 404, la cabecera HSTS desaparece. Si esa página es la primera que ve un nuevo visitante, la política no se memoriza. Un atacante puede explotar esa brecha.

Enviar HSTS por HTTP

Técnicamente, los navegadores ignoran la cabecera recibida por HTTP (RFC §8.1). En la práctica, eso indica una configuración aproximativa y altera las auditorías. Envía HSTS únicamente en los bloques HTTPS.

Cookies sin atributo Secure

HSTS fuerza HTTPS a nivel de navegador, pero en un navegador no compatible o en la primera visita, un cookie sin Secure puede filtrarse. Combina sistemáticamente HSTS y Set-Cookie: ... ; Secure; HttpOnly; SameSite=Lax.

Preload sin includeSubDomains

Técnicamente imposible: el servicio hstspreload.org rechaza cualquier envío sin includeSubDomains. Algunas configuraciones desplegadas activan preload sin includeSubDomains. Resultado: la cabecera se sirve pero el dominio nunca se integra, lo que crea una falsa impresión de protección.

Certificado autofirmado en staging

Un desarrollador se conecta a staging.captaindns.com servido por un certificado autofirmado, y luego visita la producción captaindns.com. Tras activar HSTS con includeSubDomains, el desarrollador ya no puede acceder a staging: el navegador rechaza el certificado autofirmado. Solución: usa un certificado Let's Encrypt mediante un DNS challenge, o coloca el staging en un dominio dedicado no cubierto por la política.

Redirección 302 en lugar de 301

La prueba de preload exige un 301 "Moved Permanently" en la redirección HTTP a HTTPS. Un 302 "Found" se rechaza. Verifícalo con curl -I http://captaindns.com.

Ausencia de HSTS en la respuesta de redirección

Cuando el navegador recibe la primera respuesta 301 por HTTP, sigue la redirección hacia HTTPS. Es la segunda respuesta (por HTTPS) la que debe contener HSTS. Algunas configuraciones, por descuido, colocan HSTS en la redirección HTTP (sin efecto) y la olvidan en el destino HTTPS.

HSTS en una etiqueta meta HTML

HSTS es una cabecera HTTP, no un elemento HTML. <meta http-equiv="Strict-Transport-Security" content="..."> es ignorado por todos los navegadores. Envía siempre la cabecera del lado del servidor.

Olvidarse de probar tras un cambio de infraestructura

Tras una migración a un nuevo CDN, un cambio de reverse proxy o una actualización de Terraform, la cabecera HSTS puede desaparecer silenciosamente. Integra una prueba automatizada en tu CI/CD que verifique la presencia de la cabecera en todas las rutas principales.

Verificar tu configuración HSTS con CaptainDNS

En CaptainDNS proporcionamos una herramienta dedicada para auditar tu configuración HSTS en 3 segundos, sin cuenta ni registro: el test HSTS de CaptainDNS.

La herramienta realiza tres verificaciones en paralelo:

1. Análisis de la cabecera Strict-Transport-Security: la herramienta interroga al dominio por HTTPS, captura la cabecera y parsea sus directivas. Detecta max-age, includeSubDomains, preload, así como los valores entrecomillados o mal formados que devuelven algunos servidores.
2. Consulta a la preload list de Chrome: vía la API de hstspreload.org, recupera el estado real de tu dominio (unknown, pending, preloaded, rejected) y la elegibilidad para el envío.
3. Cálculo de un grado accionable: el resultado se resume en un grado entre cinco niveles: missing (ninguna cabecera), weak (max-age demasiado bajo), good (max-age suficiente), preload-ready (elegible pero no enviado), preloaded (en la lista de Chrome).

Para cada grado inferior a preloaded, la herramienta proporciona los snippets de configuración listos para pegar para Nginx, Apache y Cloudflare. Tras desplegar la corrección, vuelve a lanzar la prueba para confirmar el paso al grado superior.

Para una visión más amplia de tus cabeceras de seguridad (CSP, X-Frame-Options, Referrer-Policy, Permissions-Policy), utiliza también nuestro Headers Viewer, que muestra la lista fiel de las cabeceras en su orden de llegada. Para probar tu redirección HTTP a HTTPS, el Redirect Checker sigue la cadena completa de redirecciones.

Si tu objetivo va más allá de HSTS y cubre la seguridad TLS del parque de correo, consulta nuestro verificador de certificados TLS para inspeccionar los certificados TLS o el check DANE/TLSA para añadir una verificación DANE/TLSA en tus servidores de correo.

FAQ

¿Qué es HSTS, en una frase?

HSTS es una cabecera de respuesta HTTP que indica al navegador que solo contacte un dominio por HTTPS durante el tiempo indicado por la directiva max-age, lo que neutraliza los ataques que intentan forzar una conexión en claro.

¿Por qué mi sitio aparece como "HSTS missing" en una prueba?

Hay tres causas posibles: la cabecera no se envía en absoluto, se envía únicamente por HTTP (por lo que los navegadores la ignoran), o se envía por HTTPS pero con una sintaxis inválida. Utiliza una herramienta como el test HSTS de CaptainDNS para aislar el problema concreto.

¿Qué valor de max-age elegir?

Para un rollout prudente, empieza con max-age=300 (5 minutos), y luego sube progresivamente por etapas (1 día, 1 semana, 1 año). Para una producción estable, max-age=31536000 (1 año) es el mínimo recomendado. Para la preload list, max-age=63072000 (2 años) es el valor más habitual. Más allá, no hay ganancia adicional de seguridad.

¿HSTS protege la primerísima visita?

No. Sin la preload list, un navegador que visita tu dominio por primera vez emite una petición HTTP antes de recibir la cabecera HSTS. Esa ventana de bootstrap sigue siendo vulnerable a un ataque man-in-the-middle. La preload list de Chrome resuelve este problema embebiendo la lista de dominios conocidos en el código fuente del navegador.

¿Puedo activar HSTS sin includeSubDomains?

Sí, pero la protección es menos robusta. includeSubDomains cubre, en particular, los cookies definidos a nivel del dominio padre. Sin esta directiva, un atacante puede forzar una petición HTTP hacia un subdominio sin HTTPS para capturar los cookies. Si todos tus subdominios pueden servir HTTPS, actívala. Si no, acepta una protección parcial.

¿Qué ocurre si desactivo HSTS por error?

Nada visible del lado del usuario mientras la política recibida previamente no haya expirado. El navegador sigue forzando HTTPS hasta el final de max-age. Para desactivar limpiamente, sirve max-age=0 durante un tiempo equivalente a tu antiguo max-age (al menos 1 año en producción estable), y luego retira por completo la cabecera.

¿Cómo probar HSTS en local sin contaminar mi navegador?

Usa un dominio de prueba dedicado (por ejemplo, un dominio .test reservado por la IETF o un second-level domain distinto del de tu producción) con un certificado Let's Encrypt obtenido mediante DNS challenge. Evita probar HSTS en tu dominio de producción desde tu puesto: una mala configuración puede bloquearte durante todo el tiempo de max-age. En desarrollo, también puedes purgar la caché HSTS de Chrome vía chrome://net-internals/#hsts, pestaña "Delete domain security policies".

¿Hay que quitar HSTS de un sitio que ya no usa HTTPS?

No, no puedes quitar HSTS sin más. Una vez que un navegador ha memorizado la política, rechazará cualquier conexión HTTP hasta la expiración de max-age. Antes de migrar un sitio a HTTP (lo cual no se recomienda), debes servir max-age=0 por HTTPS durante el tiempo previo y esperar a la expiración en los navegadores de tus visitantes.

¿Es reversible la preload list?

Técnicamente sí, en la práctica no. El procedimiento de retirada en hstspreload.org lleva de 4 a 12 semanas para la integración en Chromium, y luego entre 6 y 12 meses adicionales para que la mayoría de los usuarios hayan actualizado su navegador. Algunos usuarios nunca verán la retirada. Antes de enviar a la preload list, asegúrate de que podrás mantener HTTPS en ese dominio durante años.

¿HSTS sustituye a la redirección 301 HTTP a HTTPS?

No, la complementa. La redirección 301 es necesaria para la primerísima visita y para los usuarios que nunca han recibido la cabecera HSTS. HSTS toma el relevo en las visitas siguientes convirtiendo las URL del lado del navegador antes del envío por la red. Ambos mecanismos deben coexistir.

¿Cuántos sitios hay en la preload list en 2026?

Alrededor de 120 000 dominios están inscritos en la preload list de Chromium en abril de 2026. El archivo fuente pesa unos 18 MB. Entre estos dominios figura la mayoría de los grandes actores tech (Google, GitHub, Twitter, Facebook, PayPal) pero solo la mitad de los 20 sitios más grandes del mundo. Los sectores de finanzas, salud y administración siguen muy rezagados.

Conclusión: HSTS, la base imprescindible de toda infraestructura HTTPS

HSTS es la pieza que falta en una configuración HTTPS robusta. Sin él, la primerísima petición de cada visita sale en claro por la red, y todo el resto del tráfico depende del buen funcionamiento de la redirección 301. Con él, el navegador toma el control y convierte localmente cada URL antes incluso de que se consulte el resolvedor DNS.

Tres puntos para recordar:

1. Activa HSTS de forma progresiva. Empieza con max-age=300 para validar tu cadena HTTPS, y luego sube por etapas durante 2 a 4 semanas. Vigila los errores TLS en cada etapa.
2. Añade includeSubDomains en cuanto tus subdominios estén listos. Esta directiva cierra la puerta a los ataques por subdominio y protege tus cookies en profundidad. Haz un inventario exhaustivo antes de activarla.
3. Considera la preload list para la protección máxima. Neutraliza la vulnerabilidad del bootstrap MITM, pero es un compromiso casi irreversible. Envía solo tras 30 días de estabilidad en producción.

Para probar tu configuración HSTS ahora mismo, ve al test HSTS gratuito de CaptainDNS. La herramienta calcula tu grado, analiza tus directivas, consulta la preload list de Chrome y te proporciona los snippets de Nginx, Apache y Cloudflare listos para pegar. No se requiere cuenta, resultado en 3 segundos.