HSTS (HTTP Strict Transport Security) es una cabecera HTTP de respuesta definida por el RFC 6797. Indica al navegador que solo contacte con el dominio mediante HTTPS durante el tiempo definido por la directiva max-age. Una vez memorizada la cabecera, el navegador convierte automáticamente cualquier petición http:// en https:// antes de enviarla, lo que impide los downgrades y los ataques de SSL stripping en redes no controladas.

Test HSTS y preload: comprueba tu cabecera HTTPS

¿Por qué probar HSTS?

La cabecera HSTS es uno de los controles de seguridad HTTPS más eficaces, pero a menudo se configura mal: max-age demasiado corto, includeSubDomains olvidado o un dominio elegible para la preload list pero nunca enviado. Probar tu configuración con regularidad permite detectar estas brechas antes de que se exploten.

Tres casos de uso principales:

Auditoría de seguridad antes de la puesta en producción: validar que la cadena HTTPS, la redirección de HTTP a HTTPS y la cabecera Strict-Transport-Security son coherentes antes de abrir un nuevo dominio al público.
Preparación para la preload list: verificar los cuatro requisitos (max-age mayor o igual a 31536000, includeSubDomains, preload, redirección HTTP a HTTPS) antes de enviar el dominio a hstspreload.org.
Verificación tras una migración: tras un cambio de infraestructura (paso a Cloudflare, migración a un nuevo cluster Nginx), confirmar que la cabecera HSTS sigue enviándose con las directivas correctas en la raíz y en los subdominios.

Cómo usar el test HSTS en 3 pasos

Paso 1: Introducir el dominio

Escribe el dominio raíz sin https:// ni ruta (por ejemplo, captaindns.com). La herramienta apunta automáticamente a la versión HTTPS del sitio y sigue la redirección inicial si existe. Evita los subdominios en el primer análisis, salvo que tu objetivo sea verificar un servicio concreto (por ejemplo, api.captaindns.com).

Paso 2: Lanzar el test HSTS

Haz clic en Probar. CaptainDNS realiza tres acciones en paralelo: consulta de la cabecera Strict-Transport-Security devuelta por el servidor, petición a la preload list de Chrome para confirmar el estado y análisis de las directivas max-age, includeSubDomains y preload. El resultado completo se muestra en menos de 3 segundos.

Paso 3: Aplicar las recomendaciones

Lee tu grado (missing, weak, good, preload-ready o preloaded) y la lista de correcciones propuestas. Copia el snippet Nginx, Apache o Cloudflare adaptado a tu stack, despliégalo y vuelve a lanzar el test para confirmar el salto al grado superior. Itera hasta alcanzar preloaded si la preload list es tu objetivo.

¿Qué es HSTS?

HSTS (HTTP Strict Transport Security) es una cabecera de respuesta HTTP estandarizada por el RFC 6797 en 2012. Cuando un navegador recibe esta cabecera por una conexión HTTPS válida, memoriza el dominio y rechaza, durante el tiempo definido, cualquier conexión en claro a ese dominio. La conversión de http:// a https:// la hace localmente el navegador, antes del menor paquete de red, lo que elimina la ventana de interceptación durante la primera redirección.

La cabecera consta de tres directivas:

max-age: tiempo en segundos durante el cual el navegador aplica HSTS. Valor recomendado para producción estable: 31536000 (1 año). Para la preload list: mínimo 31536000.
includeSubDomains: extiende la protección a todos los subdominios (www, api, mail, etc.). Obligatoria para la preload list.
preload: indica el consentimiento del propietario para enviar el dominio a la preload list de Chrome. Sin esta directiva, hstspreload.org rechaza el envío.

Ejemplo de cabecera completa:

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

Sin HSTS, un usuario que escribe captaindns.com en la barra de direcciones envía primero una petición HTTP en claro. Un atacante en la misma red Wi-Fi puede interceptar esa petición y servir una versión pirata del sitio (ataque SSL stripping). HSTS hace este ataque imposible tras la primera visita legítima, y la preload list lo hace imposible desde la primera visita para los dominios precargados en el navegador.

Los 5 grados explicados

CaptainDNS asigna un grado basado en las directivas detectadas y en el estado preload. Esta es la rúbrica de calificación:

Grado	Criterio técnico	Acción recomendada
missing	Ninguna cabecera Strict-Transport-Security devuelta	Activar HSTS en el servidor, empezar por max-age=300 y luego subir
weak	Cabecera presente pero max-age inferior a 86400 (1 día)	Aumentar max-age, apuntar a un mínimo de 604800 (1 semana)
good	max-age mayor o igual a 86400, sin includeSubDomains o sin preload	Auditar los subdominios y luego añadir includeSubDomains
preload-ready	max-age mayor o igual a 31536000, includeSubDomains y preload presentes, redirección HTTP a HTTPS activa	Enviar el dominio en hstspreload.org
preloaded	Dominio confirmado en la preload list de Chrome	Vigilar la coherencia (cada subdominio debe seguir siendo accesible por HTTPS)

El grado preload-ready no significa que el dominio esté en la preload list: solo indica que cumple las condiciones técnicas para ser enviado. El envío en sí se hace en hstspreload.org y la inclusión en Chrome suele tardar entre 6 y 12 semanas.

Cómo corregir tu configuración HSTS

Estos son los snippets listos para pegar para las tres plataformas más habituales. Todos activan un HSTS conforme a los requisitos de la preload list.

Nginx

# /etc/nginx/sites-available/captaindns.com
server {
    listen 443 ssl http2;
    server_name captaindns.com;

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

La palabra clave always garantiza que la cabecera se envíe incluso en respuestas de error (4xx, 5xx). Sin ella, una página 404 no llevaría la cabecera HSTS.

Apache (mod_headers)

# /etc/apache2/sites-available/captaindns.com.conf
<VirtualHost *:443>
    ServerName captaindns.com
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</VirtualHost>

Activa el módulo con a2enmod headers si aún no lo está y luego recarga Apache.

Cloudflare Workers

addEventListener('fetch', event =&gt; {
    event.respondWith(handleRequest(event.request));
});

async function handleRequest(request) {
    const response = await fetch(request);
    const newHeaders = new Headers(response.headers);
    newHeaders.set(
        'Strict-Transport-Security',
        'max-age=31536000; includeSubDomains; preload'
    );
    return new Response(response.body, {
        status: response.status,
        statusText: response.statusText,
        headers: newHeaders,
    });
}

En Cloudflare también puedes activar HSTS desde el panel (SSL/TLS, Edge Certificates, HTTP Strict Transport Security) sin desplegar un Worker.

Tras cada cambio, vuelve a lanzar el test HSTS para confirmar que se ha aplicado en el CDN o el reverse proxy.

Inscribirse en la preload list de HSTS

La preload list es una lista de dominios codificada de forma estática en Chrome (y reutilizada por Firefox, Safari, Edge y Opera). Cualquier dominio presente en la lista lo tratan los navegadores como HTTPS-only desde la primera visita, sin necesidad siquiera de recibir la cabecera HSTS previamente.

Para enviar un dominio en hstspreload.org, debe cumplir cuatro condiciones:

max-age mayor o igual a 31536000 (1 año).
Directiva includeSubDomains presente en la cabecera.
Directiva preload presente en la cabecera.
Redirección HTTP a HTTPS activa en el dominio raíz y en todos los subdominios.

El certificado también debe ser válido (cadena completa, no autofirmado, no caducado). Una vez aceptado el envío, la inclusión en Chrome tarda de media entre 6 y 12 semanas, el tiempo necesario para que el cambio se publique en una nueva versión estable del navegador.

Advertencia sobre la irreversibilidad. La retirada de un dominio de la preload list es técnicamente posible (formulario de retirada en hstspreload.org), pero tarda varios meses y solo se aplica a las versiones futuras de Chrome. Los usuarios con versiones antiguas seguirán forzando HTTPS durante años. Antes de enviar, comprueba que cada subdominio de producción, de staging y de administración interna sea accesible por HTTPS, y que no tengas previsto migrar a otro nombre de dominio a corto plazo.

Casos de uso reales

Incidente 1: grado weak tras una auditoría ANSSI

Síntoma: una auditoría ANSSI señala que captaindns.com envía una cabecera HSTS, pero que el valor de max-age (3600) es demasiado bajo para ofrecer una protección real.

Diagnóstico: el test HSTS confirma la presencia de la cabecera Strict-Transport-Security: max-age=3600. Ninguna directiva includeSubDomains ni preload. El grado asignado es weak.

Acción: modificar la configuración de Nginx para pasar a max-age=31536000; includeSubDomains; preload, tras validar que todos los subdominios (api, mail, status) responden por HTTPS. Volver a lanzar el test: el grado pasa a preload-ready.

Incidente 2: subdominio roto tras activar includeSubDomains

Síntoma: tras activar includeSubDomains en captaindns.com, la herramienta interna metrics.captaindns.com deja de ser accesible para los equipos. Error "ERR_SSL_PROTOCOL_ERROR" en Chrome.

Diagnóstico: el subdominio metrics solo dispone de un endpoint HTTP. La directiva includeSubDomains, memorizada por los navegadores de los equipos, fuerza ahora HTTPS, pero no se sirve ningún certificado en ese subdominio.

Acción: desplegar de urgencia un certificado Let's Encrypt en metrics, o retirar temporalmente la directiva includeSubDomains y vaciar la caché HSTS local de los equipos (chrome://net-internals/#hsts) mientras se devuelve el subdominio al cumplimiento.

Incidente 3: dominio preload-ready nunca enviado

Síntoma: durante una auditoría de seguridad interna, el test revela que captaindns.com lleva más de un año en preload-ready, pero no está en la preload list de Chrome. Los nuevos visitantes siguen siendo vulnerables al SSL stripping en la primera visita.

Diagnóstico: la configuración del servidor es correcta (max-age=31536000, includeSubDomains, preload, redirección HTTP a HTTPS). El estado preload devuelto por Chrome es "Not in preload list".

Acción: enviar el dominio en hstspreload.org. Seguir la confirmación y luego esperar entre 6 y 12 semanas para la propagación en la versión estable de Chrome. Documentar la decisión y su irreversibilidad en el registro interno de seguridad.

FAQ - Preguntas frecuentes

P: ¿Qué es HSTS?

R: HSTS (HTTP Strict Transport Security) es una cabecera HTTP de respuesta definida por el RFC 6797. Indica al navegador que solo contacte con el dominio por HTTPS durante el tiempo definido por max-age. Una vez memorizada la cabecera, el navegador convierte cualquier petición http:// en https:// antes de enviarla, lo que impide los downgrades y los ataques de SSL stripping en redes no controladas.

P: ¿Qué valor de max-age elegir para HSTS?

R: Para una puesta en producción prudente, empieza por max-age=300 (5 minutos) para probar sin compromiso. Una vez validada la cadena HTTPS, sube progresivamente a 86400 (1 día) y luego a 604800 (1 semana). Para la preload list, el valor mínimo exigido es 31536000 (1 año), que también es el valor recomendado en producción estable. Un valor más alto no aporta ningún beneficio adicional.

P: ¿Es reversible el preload de HSTS?

R: Sí, pero en la práctica de forma muy lenta. Puedes solicitar la retirada en hstspreload.org, pero la operación tarda varios meses y solo se aplica a las versiones futuras de Chrome. Los usuarios con versiones antiguas seguirán forzando HTTPS durante años. Antes de enviar un dominio, asegúrate de que todos los recursos, incluidos los subdominios internos, sean accesibles por HTTPS.

P: ¿Funciona HSTS sin HTTPS?

R: No. El RFC 6797 exige que la cabecera Strict-Transport-Security se ignore cuando se recibe por HTTP. Solo las respuestas servidas en una conexión TLS válida pueden activar HSTS en el navegador. Por tanto, debes desplegar primero un certificado válido (Let's Encrypt, por ejemplo) y redirigir todo el tráfico HTTP a HTTPS antes de enviar la cabecera.

P: HSTS y redirección HTTPS, ¿qué diferencia hay?

R: Una redirección 301 de HTTP a HTTPS la ejecuta el servidor después de que la petición en claro haya salido del dispositivo. Un atacante en posición de man-in-the-middle puede interceptar esa primera petición. HSTS resuelve el problema: tras la primera visita, el propio navegador convierte http:// en https:// antes de cualquier envío de red. La redirección sigue siendo necesaria para la primera visita y para los clientes que nunca han recibido la cabecera.

P: ¿Hay que activar includeSubDomains?

R: Sí, en cuanto todos los subdominios (www, api, mail, admin, intranet, etc.) sean accesibles por HTTPS. La directiva includeSubDomains extiende la protección HSTS a todo el dominio y es obligatoria para la preload list. Antes de activarla, audita cada subdominio activo: un subdominio interno en HTTP (por ejemplo, una herramienta de monitorización) quedará inaccesible en cuanto los navegadores memoricen la cabecera.

Herramientas complementarias

El test HSTS se combina con otras herramientas CaptainDNS para cubrir la seguridad HTTP, DNS y mail:

Herramienta	Utilidad
Analizador de cabeceras HTTP	Vista exhaustiva de las security headers (CSP, X-Frame-Options, Permissions-Policy) con una nota de A a F
Redirect Checker	Verificar la cadena de redirección HTTP a HTTPS, exigida para la preload list
DNSSEC Check	Defensa en profundidad en el lado DNS: completar la seguridad HTTPS con la firma de la zona
MTA-STS Record Check	Equivalente HSTS para SMTP: forzar TLS en los flujos de correo entrante
Uptime Monitor	Monitorización continua para detectar una regresión HSTS en cuanto ocurra
Page Crawl Checker	Auditoría on-page completa (HTML, cabeceras, comportamiento) para validar una puesta en producción

Recursos útiles

Guía completa HSTS y preload list de CaptainDNS (guía de referencia para activar Strict-Transport-Security paso a paso: directivas, configuraciones de Nginx, Apache, Cloudflare, AWS, Caddy, envío a la preload list)
hstspreload.org (formulario oficial de envío a la preload list de Chrome)
MDN: Strict-Transport-Security (documentación de referencia sobre la cabecera HSTS y sus directivas)
RFC 6797 (especificación original de HTTP Strict Transport Security)
OWASP HSTS Cheat Sheet (buenas prácticas de despliegue de HSTS)
content-security-policy.com (guía práctica sobre HSTS y ejemplos de configuración)

Test HSTS y verificación de la preload list

Audita tu cabecera Strict-Transport-Security y la preload list