HSTS (HTTP Strict Transport Security)
Se lee en aproximadamente 4 minutos
Última actualización: 2026-09-01
Qué es HSTS
HSTS (HTTP Strict Transport Security) es un mecanismo de seguridad en el que el servidor web instruye al navegador a "usar siempre HTTPS para acceder a este dominio en adelante". Se activa agregando el encabezado Strict-Transport-Security a la respuesta HTTP, y la especificación se estandarizó como RFC 6797 (noviembre de 2012).
Sin HSTS configurado, cuando un usuario accede a http://example.com, la comunicación se realiza en texto plano durante el instante hasta que el servidor redirige a HTTPS. Un ataque de intermediario (SSL stripping) puede aprovechar este momento. Una vez que el navegador ha recibido la política HSTS, reescribe la URL a HTTPS antes de enviar la solicitud, por lo que ese intercambio en texto plano deja de producirse.
El segundo pilar es el tratamiento de los errores de certificado. Si la validación del certificado falla en un dominio cubierto por HSTS, el navegador debe interrumpir la conexión y el usuario no puede continuar desde una pantalla de advertencia como haría normalmente. Aunque un atacante presente un certificado falsificado, ninguna acción del usuario permite forzar el paso, y ahí está la diferencia con HTTPS a secas.
Por otro lado, el navegador solo conoce esta instrucción después de recibir el encabezado. La primera visita al dominio no queda cubierta por HSTS, y el propio RFC señala esto como una debilidad. La lista Preload que se describe más adelante existe para cerrar esa brecha.
Configuración y directivas de HSTS
HSTS se configura con el siguiente encabezado de respuesta.
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
- max-age: Segundos durante los cuales el navegador recuerda la política HSTS. 31536000 (1 año) es además el mínimo que exigen los requisitos de la lista Preload, por lo que es el valor más habitual. Para la implementación inicial, es seguro comenzar con 300 (5 minutos) o 86400 (1 día) y extender gradualmente si no hay problemas.
- includeSubDomains: Aplica HSTS también a los subdominios. Verificar que todos los subdominios como
api.example.comocdn.example.comson compatibles con HTTPS antes de activarlo. Si hay subdominios que solo operan con HTTP, esos subdominios se volverán inaccesibles. - preload: Indicador de intención de registro en la lista HSTS Preload. RFC 6797 define solo dos directivas, max-age e includeSubDomains; preload se añadió después para la lista del lado del navegador y queda fuera de la especificación. Como la especificación exige ignorar las directivas desconocidas, añadir el indicador por sí solo no produce ningún efecto y el registro requiere una solicitud por separado.
Entre los encabezados de seguridad, HSTS tiene pocos parámetros que ajustar y puede forzar de manera confiable la comunicación cifrada mediante TLS/SSL. Tenga en cuenta, sin embargo, que una vez que el navegador ha guardado la política, el dominio no puede volver a servirse por HTTP hasta que expire max-age. Confirme hasta dónde llega su cobertura de HTTPS y comience con un max-age pequeño para ampliarlo después.
Funcionamiento de la lista HSTS Preload
El HSTS normal tiene el "problema de la primera visita". El navegador recibe el encabezado HSTS en el primer acceso HTTPS, por lo que HSTS no funciona cuando el usuario accede al dominio por primera vez.
La lista HSTS Preload responde a este problema. Es una lista de dominios compatibles con HSTS incorporada en los navegadores: la lista que se distribuye en el código fuente de Chrome es la original, y Firefox, Safari y Edge mantienen listas derivadas de ella. Las solicitudes se envían a través de hstspreload.org y, una vez registrado el dominio, HTTPS se fuerza desde el principio incluso para dominios que el usuario nunca ha visitado.
Los requisitos para el registro en la lista Preload son los siguientes.
- Usar un certificado digital válido
- Si se atiende el puerto 80, redirigir de HTTP a HTTPS en el mismo nombre de host
- Servir todos los subdominios por HTTPS (incluido
wwwsi existe un registro DNS para él, y los subdominios internos que no son de acceso público) max-agede 31536000 (1 año) o más- Incluir las directivas
includeSubDomainsypreload
La principal precaución es lo difícil que resulta revertirlo. Incluso después de solicitar la eliminación, el cambio tarda varios meses en llegar a los usuarios a través de las actualizaciones del navegador, y el sitio indica expresamente que no se garantiza su propagación a navegadores distintos de Chrome. Los registros nuevos también tardan meses en llegar a las versiones estables. Verifique cuidadosamente que todos los subdominios son compatibles con HTTPS antes del registro.
Cabe señalar que, en agosto de 2026, hstspreload.org sostiene que, si bien se recomienda HSTS en sí, no se recomienda la precarga. Chrome y Safari ya elevan las navegaciones de página HTTP a HTTPS con independencia de que exista una política HSTS, por lo que la precarga solo ayuda en el caso concreto de que un atacante bloquee esa elevación. Trate la implementación de HSTS y el registro en la lista Preload como decisiones separadas.
Precauciones y enfoque gradual para la implementación de HSTS
HSTS es potente, pero los errores de configuración pueden hacer que el sitio sea inaccesible. Se recomienda el siguiente enfoque gradual.
- Paso 1: Configurar con
max-age=300(5 minutos) y verificar que todo el sitio funciona correctamente con HTTPS. - Paso 2: Extender a
max-age=86400(1 día) y operar durante aproximadamente una semana para confirmar que no hay problemas. - Paso 3: Expandir a
max-age=31536000; includeSubDomains. - Paso 4: Solo si decide registrarse en la lista Preload, revise las precauciones anteriores y después agregue
preloady envíe la solicitud.
El caso que requiere más atención es cualquier punto donde su propio dominio o sus subdominios se referencien por HTTP. Con includeSubDomains activado, el navegador reescribe esas referencias a HTTPS, de modo que un subdominio que no admita HTTPS simplemente no llegará a cargarse. Antes de activarlo, confirme que todos los subdominios, incluidos los de pruebas y los internos, responden por HTTPS. Los recursos servidos por HTTP desde el dominio de un tercero quedan fuera del alcance de HSTS; el navegador los bloquea como contenido mixto (Mixed Content) exista o no HSTS.
Combinando con la directiva upgrade-insecure-requests de CSP, las referencias a recursos HTTP dentro de la página se reescriben automáticamente a HTTPS, lo que puede mitigar los problemas de contenido mixto durante el período de transición.
Para obtener más información sobre este tema, consulte Cómo funcionan HTTPS y TLS - El cifrado detrás de la comunicación segura.
Conceptos erróneos comunes
- Si se redirige a HTTPS, HSTS es innecesario
- Durante la redirección de HTTP a HTTPS, la primera solicitud se envía en texto plano. En este instante puede establecerse un ataque de intermediario (SSL stripping). HSTS reescribe la solicitud HTTP a HTTPS en el lado del navegador, defendiendo contra ataques que la redirección no puede prevenir.
- Configurar HSTS se aplica inmediatamente a todos los usuarios
- El HSTS normal solo se activa cuando el navegador recibe el encabezado, por lo que no protege en la primera visita. La vía para forzar HTTPS desde la primera visita es la lista HSTS Preload, pero revertir un registro tarda varios meses, así que decida solo después de confirmar que el dominio y todos sus subdominios pueden mantenerse en HTTPS a largo plazo.