¿Qué es HSTS? HTTP Strict Transport Security explicado
HSTS indica al navegador que cargue tu sitio solo por HTTPS: sin degradaciones y sin posibilidad de saltarse los errores de certificado. Así funciona, así se activa en nginx, Apache, IIS y Cloudflare, y así se precarga con seguridad.
Ejecuta la misma comprobación ahora — gratis
Introduce tu dominio y obtén una auditoría de 9 puntos — DNS, SPF/DKIM/DMARC, SSL, cabeceras de seguridad, exposición en dark web — en 60 segundos.
Sin registro · <60s · Procesamiento GDPR/UE
Tu sitio probablemente ya redirige a HTTPS y el candado se muestra sin problemas. Pero cada vez que un visitante habitual escribe tu dirección sin https://, su navegador envía una petición HTTP sin cifrar antes de que tu redirección actúe. En redes hostiles - Wi-Fi de aeropuerto, hoteles, un router comprometido - esa única petición es la puerta que necesita un atacante. HTTP Strict Transport Security (HSTS) la cierra definitivamente: una sola cabecera de respuesta que ordena al navegador no volver a hablar HTTP plano con tu dominio.
La brecha es real: según W3Techs (julio de 2026), el 90,1 % de los sitios web ya usa HTTPS por defecto, pero solo el 34,1 % envía una cabecera HSTS. Nueve de cada diez cifran; apenas uno de cada tres lo impone.
¿Qué es HSTS?
HSTS (HTTP Strict Transport Security) es un mecanismo de política de seguridad web estandarizado en el RFC 6797 en 2012. Consiste en una única cabecera de respuesta HTTP:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Cuando el navegador recibe esta cabecera a través de una conexión HTTPS válida, recuerda - durante max-age segundos - que tu host es solo HTTPS. A partir de ese momento:
- Todo enlace
http://, marcador o dirección escrita de tu dominio se reescribe ahttps://dentro del navegador (una redirección 307 interna), antes de que un solo paquete salga del dispositivo. - Los avisos de certificado en tu sitio pasan a ser imposibles de omitir: no hay enlace de "Continuar de todos modos". Si el certificado está roto - o alguien intercepta la conexión - el navegador se niega, sin excepciones.
Todos los navegadores importantes - Chrome, Edge, Firefox, Safari - llevan aproximadamente una década soportando HSTS, en escritorio y móvil.
Por qué una redirección HTTPS no basta
Una redirección 301 clásica de HTTP a HTTPS ocurre en el servidor: el navegador debe enviar primero la petición HTTP en claro, y un atacante situado entre tu visitante y tu servidor la ve antes de que tu redirección responda. Así funciona exactamente el SSL stripping, un ataque de degradación demostrado por Moxie Marlinspike ya en 2009: el atacante mantiene a la víctima en HTTP mientras él habla HTTPS con el servidor real, leyendo todo lo que pasa.
| Protección | Solo redirección 301 | HSTS | HSTS + preload |
|---|---|---|---|
| Visitas posteriores actualizadas antes de tocar la red | ❌ | ✅ | ✅ |
| La primera visita protegida | ❌ | ❌ | ✅ |
| Errores de certificado imposibles de omitir | ❌ | ✅ | ✅ |
| Frena el SSL stripping (degradación) | ❌ | ✅ tras la primera visita | ✅ siempre |
Qué protege realmente cada nivel de imposición de HTTPS.
Conserva la redirección - sigue siendo necesaria para los visitantes nuevos y para optar al preload, pero entiende lo que no puede hacer por sí sola.
Cómo funciona HSTS, paso a paso
- Primera visita. El navegador carga
https://example.com, la respuesta lleva la cabeceraStrict-Transport-Securityy la política queda guardada. - Cada visita posterior. Cualquier intento de abrir
http://example.comse actualiza internamente a HTTPS. Una captura de paquetes en la red no mostraría ninguna petición en claro. - El temporizador se renueva. Cada nueva respuesta HTTPS con la cabecera reinicia
max-age, de modo que los visitantes habituales quedan protegidos indefinidamente. - Fallo duro ante certificados inválidos. Certificados caducados, autofirmados o de un intermediario producen una página de error que no se puede omitir.
Las tres directivas
| Directiva | ¿Obligatoria? | Qué hace | Valor recomendado |
|---|---|---|---|
max-age | Sí | Cuánto tiempo (en segundos) el navegador impone solo-HTTPS | 31536000 (1 año); 63072000 (2 años) también es habitual |
includeSubDomains | Para preload | Extiende la política a todos los subdominios | Solo tras confirmar que todos los subdominios sirven HTTPS |
preload | Para preload | Autoriza la inclusión en la lista integrada de los navegadores | Tras un año estable con max-age de 1 año |
Cómo activar HSTS en tu servidor
Añade la cabecera solo en la configuración HTTPS: los navegadores ignoran el HSTS enviado por HTTP plano, tal como exige la especificación.
nginx (dentro del bloque server que escucha en el 443):
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
Apache (con mod_headers activado, en el vhost HTTPS):
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
IIS (web.config):
<httpProtocol>
<customHeaders>
<add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains" />
</customHeaders>
</httpProtocol>
Cloudflare: SSL/TLS → Edge Certificates → HTTP Strict Transport Security (HSTS) → Activar, y elige el max-age y las opciones de subdominios en el panel.
Después confirma que la cabecera se envía de verdad: abre tu sitio, revisa la pestaña Red (Network) de las herramientas de desarrollo del navegador y busca strict-transport-security entre las cabeceras de respuesta - o ejecuta el escaneo gratuito de FortifyNet, que marca una política HSTS ausente o débil.
Despliégalo de forma gradual
Una política HSTS equivocada deja a los visitantes sin acceso a cualquier recurso roto solo-HTTP durante todo el max-age restante: no puedes revocarla a distancia salvo sirviendo max-age=0 por HTTPS válido a cada navegador afectado. Escala por etapas:
| Etapa | Valor de la cabecera | Mantén |
|---|---|---|
| 1 - Prueba | max-age=300 | Uno o dos días |
| 2 - Corto | max-age=86400 | Una semana |
| 3 - Medio | max-age=2592000 | Un mes |
| 4 - Completo | max-age=31536000; includeSubDomains | 3+ meses |
| 5 - Preload | max-age=31536000; includeSubDomains; preload | Permanente |
Preload de HSTS: cerrar la brecha de la primera visita
El HSTS básico es confianza en el primer uso: la primera petición de un visitante totalmente nuevo sigue expuesta hasta que llega la primera cabecera. La lista de preload lo resuelve: tu dominio viaja dentro del propio navegador como solo-HTTPS, de modo que ni siquiera la visita número uno toca HTTP plano.
La solicitud es gratuita en hstspreload.org (la lista mantenida por Chromium, que también usan Edge, Firefox y Safari). Los requisitos:
- Un certificado TLS válido.
- HTTP redirige a HTTPS en el mismo host (puerto 80 → 443).
- La cabecera HSTS servida en la respuesta HTTPS del dominio base con
max-agede al menos 31536000 (1 año), másincludeSubDomainsypreload. - Todos los subdominios - incluido
www- accesibles por HTTPS.
Trata el preload como una puerta de un solo sentido. Salir de la lista tarda meses en propagarse por las versiones de los navegadores. No precargues hasta que cada subdominio - incluidos los internos como intranet. o mail. - tenga HTTPS operativo.
Adopción en 2026: HTTPS en todas partes, la imposición se queda atrás
HTTPS es casi universal; solo un tercio de los sitios lo impone con HSTS (fuente: W3Techs, julio de 2026).
Los navegadores empujan con fuerza en la misma dirección. En Chrome 147 (abril de 2026), Google activó "Usar siempre conexiones seguras" para los más de 1.000 millones de usuarios con Navegación Segura Mejorada, y con Chrome 154 (octubre de 2026) será el comportamiento por defecto para todos: Chrome intentará HTTPS primero y avisará antes de cargar sitios HTTP públicos.
¿Hace eso a HSTS obsoleto? No. El aviso de Chrome se puede omitir; HSTS es la garantía no omitible de tu propio servidor. Funciona en todos los navegadores sea cual sea su configuración, cubre todos tus subdominios y bloquea el salto de errores de certificado. Ambos se complementan.
Errores comunes con HSTS
- Activar
includeSubDomainsa ciegas: un subdominio solo-HTTP olvidado (intranet, staging, el portal de una impresora) queda inaccesible durante todo elmax-age. - Enviar la cabecera por HTTP: inofensivo pero inútil; los navegadores la ignoran.
- Un
max-agede pocos minutos en producción: protección casi nula y no cumple los requisitos de preload. - Olvidar HSTS tras migrar de servidor o CDN: la política caduca en silencio y nadie se da cuenta.
Preguntas frecuentes
¿HSTS sustituye a mi redirección de HTTP a HTTPS? No. Mantén la redirección: los visitantes nuevos la necesitan y la lista de preload la exige.
¿Puedo deshacer HSTS?
Sirve Strict-Transport-Security: max-age=0 por HTTPS y los navegadores descartarán la política en su siguiente visita. Salir del preload es mucho más lento - meses, por eso conviene escalar con cuidado.
¿Afecta HSTS al SEO? Solo positivamente: garantiza que usuarios y rastreadores lleguen a una única versión canónica HTTPS de tu sitio. No tiene ninguna contrapartida para el posicionamiento.
¿Cómo sé si mi sitio envía HSTS?
Revisa las cabeceras de respuesta en las herramientas de desarrollo del navegador (pestaña Red) y busca strict-transport-security, o ejecuta un escaneo gratuito de FortifyNet, que comprueba HSTS junto con el resto de tus cabeceras de seguridad.
¿Basta con HSTS? Es una de varias cabeceras que envía un sitio bien protegido. Combínala con Content-Security-Policy, X-Content-Type-Options y compañía: consulta nuestra guía completa de cabeceras de seguridad.
Comprueba tu HSTS en 60 segundos
El escaneo gratuito de FortifyNet analiza tu configuración SSL/TLS, HSTS y el resto de cabeceras de seguridad, DNS y autenticación de correo, y tu exposición en la dark web - en aproximadamente un minuto y sin registro. Si HSTS falta o está mal configurado, verás exactamente qué corregir.
Guías relacionadas
Frequently Asked Questions
Verifica tu dominio ahora
Ejecuta una auditoría gratuita y comprueba si tu dominio tiene los problemas descritos.
