Cómo implementar la seguridad de transporte estricta HTTP

Qué hace HSTS y por qué importa

HTTP Strict Transport Security (HSTS) es una política de seguridad definida en la RFC 6797. Una web la envía como cabecera de respuesta a través de HTTPS y el navegador la recuerda. Durante el tiempo que indique el sitio, el navegador reescribirá automáticamente cualquier enlace http:// a https:// antes de enviar la petición y no permitirá que el usuario ignore los errores de certificado de ese host.

Sin HSTS, un visitante que escribe example.com en la barra de direcciones suele hacer una primera petición por HTTP sin cifrar y después es redirigido a HTTPS. Esa primera petición sin cifrar es una oportunidad para que un atacante en la misma red, como un punto Wi-Fi malicioso, intercepte la conexión y mantenga al usuario en HTTP (una técnica conocida como SSL stripping). HSTS cierra esa ventana en todas las visitas posteriores a la primera vez que el navegador ve la cabecera, y la lista de precarga la cierra incluso en la primera visita.

HSTS no sustituye al propio HTTPS. Es una capa sobre una configuración TLS correcta que indica a los navegadores que nunca vuelvan atrás.

La sintaxis de la cabecera

La cabecera tiene una directiva obligatoria y dos opcionales:

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

Hay algunas reglas fáciles de pasar por alto:

• Los navegadores ignoran la cabecera si llega por HTTP sin cifrar. Solo cuenta cuando se entrega a través de una conexión HTTPS válida.
• Cada vez que el navegador recibe la cabecera, la cuenta atrás se reinicia, así que un sitio visitado con regularidad queda protegido en la práctica de forma indefinida.
• Envía una sola cabecera Strict-Transport-Security. Los duplicados, a menudo causados por definirla tanto en la aplicación como en el servidor web, pueden hacer que se ignore la política.

Requisitos previos antes de activarlo

Como HSTS elimina la opción de volver a HTTP, prepárate con cuidado. Repasa primero esta lista:

1. Certificados válidos en todas partes. Cada nombre de host cubierto debe servir un certificado de confianza, sin caducar y que coincida con el nombre.
2. Una redirección de HTTP a HTTPS que funcione. Las peticiones al puerto 80 deben devolver un 301 a la versión HTTPS de la misma URL.
3. Nada de contenido mixto. Scripts, imágenes, fuentes y llamadas a API deben cargarse por HTTPS. HSTS actualiza los enlaces a tu propio host, pero los recursos de terceros por HTTP seguirán bloqueados o marcados.
4. Un inventario de subdominios. Enumera todos los subdominios de tu zona DNS, incluidos los hosts de pruebas antiguos, los portales de webmail, las herramientas internas y las páginas alojadas por proveedores mediante CNAME. Cualquiera que no admita HTTPS dejará de funcionar al añadir includeSubDomains.
5. Una renovación de certificados fiable. Renovación automática (por ejemplo, mediante ACME) más una monitorización independiente de la caducidad.

Para los pasos de inventario y monitorización ayuda un control de renovaciones: puedes registrar cada certificado y dominio en el seguimiento de dominios de TLDix y recibir alertas mucho antes de que algo caduque.

Un despliegue seguro y por fases

El mayor error con HSTS es pasar directamente a una política de un año con includeSubDomains. Si algo falla, los visitantes que ya han recibido la cabecera siguen obligados a usar HTTPS hasta que vence el max-age, y no puedes retirarla de sus navegadores. Un enfoque por fases limita el alcance de los daños:

Las duraciones son orientaciones, no reglas. Pasa a la siguiente fase solo después de revisar los registros y los avisos de los usuarios sobre cualquier cosa que haya dejado de funcionar.

Configurar HSTS en los servidores más comunes

Nginx

Añade la cabecera dentro del bloque de servidor HTTPS. El parámetro always hace que Nginx la envíe también en las respuestas de error.

server {
    listen 443 ssl;
    server_name example.com www.example.com;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    # ssl_certificate and other directives here
}

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

Recuerda que en Nginx un add_header dentro de un bloque location anidado sustituye a las cabeceras heredadas del nivel de servidor, así que repítelo donde haga falta o usa un archivo include.

Apache

Activa mod_headers y añade la directiva al host virtual SSL:

<VirtualHost *:443>
    ServerName example.com
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</VirtualHost>

<VirtualHost *:80>
    ServerName example.com
    Redirect permanent / https://example.com/
</VirtualHost>

CDN y frameworks de aplicaciones

Muchas CDN y proxies inversos ofrecen un interruptor de HSTS en su panel, y la mayoría de los frameworks web tienen un middleware para ello. Elige un único lugar para definir la cabecera. Si la añaden tanto la CDN como el servidor de origen, puedes acabar con valores duplicados o contradictorios.

La lista de precarga de HSTS

Los principales navegadores incluyen una lista integrada de dominios que funcionan solo con HTTPS desde la primera petición. Estar en ella elimina el hueco de la confianza en el primer uso. La lista se gestiona a través del sitio de solicitudes hstspreload.org, y sus requisitos (consulta allí la versión vigente) suelen incluir:

• Un certificado válido y una redirección de HTTP a HTTPS en el mismo host.
• Todos los subdominios servidos por HTTPS.
• La cabecera en el dominio base con un max-age largo (al menos un año en el momento de escribir esto), includeSubDomains y preload.

La precarga es un compromiso a largo plazo. Es posible salir de la lista, pero el cambio solo llega a los usuarios a medida que los navegadores publican actualizaciones, lo que puede tardar meses. Algunos TLD están precargados por completo, lo que significa que todos los dominios bajo ellos son solo HTTPS por defecto en los navegadores compatibles. Si estás eligiendo un nombre nuevo, puedes revisar opciones con la herramienta de búsqueda de dominios y tenerlo en cuenta.

HSTS y otras cabeceras de seguridad

HSTS suele desplegarse junto a otras cabeceras de respuesta, y conviene entender en qué se diferencian. Content-Security-Policy con la directiva upgrade-insecure-requests indica a los navegadores que carguen por HTTPS los subrecursos de tus páginas, lo que complementa a HSTS cuando el contenido antiguo todavía tiene enlaces HTTP a terceros. HSTS, en cambio, regula cómo se conecta el navegador a tu propio host. Ninguna sustituye a la otra y es habitual usar ambas en sitios maduros. Revísalas juntas cada vez que cambies de CDN o de proxy inverso, porque una reconstrucción de la configuración puede eliminar varias cabeceras a la vez.

Probar y verificar tu política

Confirma la cabecera desde la línea de comandos:

curl -sI https://example.com | grep -i strict-transport-security

Después comprueba el comportamiento, no solo que esté presente:

• Solicita http://example.com y confirma que redirige a HTTPS con un 301.
• En navegadores basados en Chromium, la página interna net-internals/#hsts permite consultar si un dominio tiene una política guardada y eliminarla durante las pruebas.
• Prueba cada subdominio por HTTPS antes de añadir includeSubDomains, incluidos los que apenas se usan.
• Vuelve a probar tras cada despliegue, cambio de CDN o migración de servidor, ya que las cabeceras suelen perderse cuando se reconstruye la configuración.

Errores habituales y cómo evitarlos

• Subdominios olvidados. Un antiguo host de intranet o una página de un proveedor en un CNAME sin certificado fallará en cuanto se aplique includeSubDomains. Revisa antes el DNS.
• Caducidad del certificado. Con HSTS, los navegadores bloquean por completo el acceso cuando un certificado no es válido. Un certificado vencido pasa de ser un aviso a una caída total. Vigila las fechas de caducidad con independencia de tu automatización de renovaciones.
• Enviar la cabecera en respuestas HTTP. Ahí se ignora, así que no protege nada y puede confundir las auditorías.
• Dominios de desarrollo. Evita enviar HSTS desde hosts locales o de pruebas que compartan dominio padre con producción, salvo que también admitan HTTPS.
• Dar marcha atrás. Para retirar una política, sirve max-age=0 por HTTPS. Los navegadores que lo vean olvidarán la regla, pero los que no vuelvan la conservarán hasta que caduque.

HSTS funciona mejor como parte de un plan de refuerzo más amplio. Combínalo con registros CAA para controlar qué autoridades pueden emitir certificados y repasa las buenas prácticas de seguridad de dominios para la parte de cuentas y DNS.

Mantener HSTS en buen estado con el tiempo

Una vez desplegado, HSTS requiere poca atención mientras HTTPS siga funcionando bien. Incorpora algunos hábitos a tu operativa: mantén actualizado el inventario de subdominios, incluye la comprobación de la cabecera en las pruebas de despliegue y controla todas las fechas de renovación de certificados y dominios. Al auditar propiedades antiguas, puedes consultar dónde está alojado un sitio y confirmar los detalles con la consulta de hosting. La política solo es tan fiable como los certificados y registros de dominio que la sustentan, así que trata las renovaciones como parte del mismo control de seguridad.

Documenta la política aplicada

Anota qué valor de max-age usa cada dominio, si incluye subdominios, si se ha solicitado la precarga y en qué capa (CDN, proxy o aplicación) se define la cabecera. Esa nota evita configuraciones duplicadas y permite que cualquier persona del equipo entienda rápidamente qué consecuencias tendría un cambio de infraestructura.