Tu web sigue siendo insegura sin políticas estrictas de HSTS

La mentira del HTTPS: El "pecado original" de la redirección

Muchos desarrolladores creen que por tener el candadito verde (o gris, según tu navegador) ya están a salvo. Pero hay un problema: los navegadores son vagos por naturaleza.

Cuando escribes twitter.com en la barra de direcciones, el navegador no sabe si hablas HTTPS o HTTP. Por defecto, intenta la vía fácil: el puerto 80 (HTTP). Tu servidor, que es muy educado, le responde con un redirect 301: “Eh, vete por el puerto 443”.

Ese milisegundo entre la petición HTTP y la redirección es el paraíso para un atacante.

La Analogía del Camión Blindado

Imagina que tienes que enviar un millón de euros en un camión blindado (HTTPS). Pero para que el camión llegue a tu puerta, primero tienes que llamar por un megáfono en la calle (HTTP) para pedirlo. Un ladrón que esté escuchando puede interceptar tu llamada y mandarte una furgoneta de helados disfrazada (SSL Stripping). Tú verás la furgoneta, pensarás que es el camión, y entregarás el dinero. El ladrón se lo lleva, y tú ni te has enterado porque la furgoneta parece “oficial”.

HSTS es como poner un cartel en tu puerta que dice: “Solo acepto camiones blindados. Si viene una furgoneta de helados, ni le abras la puerta”. A partir de ese momento, el navegador ya no “pregunta” por megáfono; simplemente asume que todo debe ser blindado.

¿Qué ocurre realmente en las tripas del navegador?

Cuando tu servidor envía la cabecera HSTS, el navegador guarda esa información en una base de datos local (puedes verla en Chrome escribiendo chrome://net-internals/#hsts). A partir de ese instante, ocurre algo mágico llamado Internal Redirect.

Si intentas entrar por HTTP, el propio navegador cancela la petición antes de que salga de tu tarjeta de red y la transforma en HTTPS. El atacante ya no tiene red que interceptar porque la petición “insegura” nunca llega a existir fuera de tu RAM.

Visualizando el Ataque: Cómo muere un SSL standard

La conexión olvidada: HSTS y tus Cookies de Sesión

El efecto secundario positivo: Una vez que HSTS está activo y el navegador ha “aprendido” la política, cualquier petición a tu dominio será HTTPS por defecto. Esto significa que incluso si se te olvida poner el flag Secure en algunas cookies técnicas, el navegador las tratará con el máximo respeto porque el canal de transporte está blindado por contrato. Sin embargo, en AldeaCode siempre recomendamos duplicar la seguridad: HSTS en el transporte y Secure; HttpOnly; SameSite=Lax en las cookies. No dejes puertas abiertas.

¿Por qué la AEPD se ha vuelto tan estricta en 2026?

La razón es simple: la Diligencia Proactiva. Antes, si te hackeaban, podías decir que habías hecho “lo normal”. Hoy, “lo normal” incluye HSTS. En las últimas resoluciones que hemos analizado (como las de grandes aseguradoras y retailers), la falta de HSTS se cita como una “omisión de medidas técnicas básicas de cifrado en tránsito”. Ya no solo proteges tus datos; proteges tu cuenta bancaria de multas que pueden llegar a ser existenciales para una empresa.

Recomendación de trinchera:

1. Nunca empieces con un max-age de 2 años. Empieza con 5 minutos (300 segundos).
2. Verifica que todas tus herramientas internas, subdominios de logs y entornos de desarrollo tienen HTTPS.
3. Solo cuando estés 100% seguro de que nada se ha roto, sube el max-age gradualmente: una semana, un mes, y finalmente los dos años reglamentarios para el Preload.

Configuración Paso a Paso: El "Zen" de las cabeceras Perfectas

Configurar HSTS no es solo copiar y pegar una línea. Dependiendo de tu stack, la implementación puede variar drásticamente. Aquí tienes el manual definitivo para los tres entornos más comunes.

1. Nginx: El Flag ‘always’ y por qué es crítico

En Nginx, muchos desarrolladores cometen el error de poner la cabecera sin el parámetro always.

El peligro: Si Nginx detecta un error (como un 500 Internal Server Error) y no tienes el flag always, el servidor no enviará la cabecera HSTS en esa respuesta. Si el usuario recibe un error en una red insegura, su navegador podría “olvidar” la regla HSTS justo cuando más la necesita.

# 63072000 segundos = 2 años
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
# Si usas un Proxy Inverso (como detras de un balanceador), asegúrate de que el SSL termine aquí o que la cabecera se pase correctamente.

2. Apache: El módulo mod_headers

Si estás en un hosting compartido o usas Apache, la vida es un poco más ruda. Necesitas asegurarte de que el módulo headers esté activo. Sin él, tu .htaccess provocará un error 500 y tirarás la web.

<IfModule mod_headers.c>
    # Usamos 'set' para sobrescribir cualquier cabecera previa
    Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
</IfModule>

3. Cloudflare: La vía rápida (y peligrosa)

Si usas Cloudflare, puedes activar HSTS con un solo clic en el panel de SSL/TLS -> Edge Certificates -> HSTS.

Mi consejo de experto: Ten cuidado. Activar includeSubDomains en Cloudflare es irreversible a nivel de caché del navegador. Si tienes un subdominio que no pasa por el proxy de Cloudflare (la nube naranja apagada) y no tiene SSL, se quedará inaccesible para todos tus usuarios. Cloudflare te da el poder, pero tú eres el responsable de las consecuencias.

[!WARNING] Antes de lanzar: Verifica que no tienes subdominios técnicos (ej: printer.empresa.local o dev.legacy.com) que solo funcionen por HTTP. HSTS los bloqueará instantáneamente para cualquier usuario que haya visitado el dominio principal.

Checklist de Cumplimiento LOPDGDD 2026

Lecciones de las multas de 2025: A menudo nos preguntan: “¿De verdad me pueden multar por no tener una cabecera?”. Basándonos en los casos de Generali (€5M) y Carrefour (€3M), la respuesta es un rotundo sí. La AEPD ya no acepta la “inacción técnica” como excusa. Si lanzas un ecommerce en 2026 sin HSTS, eres legalmente responsable de las interceptaciones de sesión que ocurran en redes públicas.

Cómo verificar HSTS (como un Pro)

No te fíes de lo que dice tu código; fíjate en lo que recibe el navegador. Tienes tres formas de verificarlo:

1. La Pestaña de Network (F12): Entra en tu web, haz clic en el primer recurso (el documento HTML) y busca Strict-Transport-Security en los Headers de Respuesta.
2. La Consola de Chrome: Escribe chrome://net-internals/#hsts en tu barra de direcciones. Puedes buscar tu dominio allí y ver si el navegador lo ha “fichado”.
3. El Comando de Terminal (Curl):

   curl -I https://tuweb.com

La HSTS Preload List: Blindaje "Modo Dios"

HSTS tiene una debilidad: la primera visita (TOFU - Trust On First Use). Si un usuario nunca ha entrado a tu sitio, su navegador no sabe que debe forzar HTTPS.

La Preload List es una base de datos incluida directamente en el código fuente de los navegadores (Chrome, Safari, Edge). Si tu dominio está allí, el navegador jamás intentará conectar por HTTP, ni siquiera la primera vez.

Requisitos Auditados para Preload:

1. Servir un certificado SSL válido.
2. Redirigir todo el puerto 80 al puerto 443 en el mismo host.
3. Servir todos los subdominios sobre HTTPS.
4. La cabecera debe tener max-age ≥ 31,536,000s, includeSubDomains y preload.

Una vez configurado, envía tu dominio para inspección en: hstspreload.org.

HSTS-only mode y el Roadmap de seguridad 2026

¿Hacia dónde vamos? La tendencia en los navegadores modernos (como las últimas versiones de Chrome y Firefox) es el “HTTPS-First Mode”. Sin embargo, esto no sustituye a HSTS; lo complementa.

En un futuro cercano, el objetivo es eliminar por completo la necesidad de que el servidor responda por el puerto 80. HSTS es el puente necesario para esta transición. Al forzar una política de transporte estricta, estás comunicando a la red que tu sitio ha nacido para vivir en el cifrado.

Mi predicción para 2026: Veremos una integración más profunda de HSTS con los registros de DNS (mediante el registro HTTPS SVCB/HTTPS). Esto permitirá que el navegador sepa que debe usar HTTPS incluso antes de que se resuelva la IP del servidor. Si ya tienes implementado HSTS y estás en la Preload List, tu sitio ya está preparado para esta evolución tecnológica.

Rendimiento y SEO Técnico: La velocidad del "Zero-Redirect"

HSTS mejora tu ranking por dos vías que a menudo pasan desapercibidas para los consultores SEO junior:

1. Eliminación de Latencia (TTFB): Al evitar el redirect 301 en el servidor, el navegador salta directamente a la conexión segura. En conexiones móviles (4G/5G), esto ahorra entre 200ms y 500ms de latencia inicial. Google ama los sitios que responden rápido, y eliminar un viaje de ida y vuelta al servidor es la optimización más pura que existe.
2. Canonicalización Forzada: Evita que Google indexe versiones HTTP de tus URLs. Se acabó el drama de tener http://tuweb.com y https://tuweb.com compitiendo en las SERPs. Con HSTS, la versión HTTP deja de existir permanentemente para el bot.

Para perfeccionar tu infraestructura técnica, combina HSTS con nuestra Guía Maestra de CSP y la protección ante riesgos de Seguridad LOPD. Si quieres automatizar todo este proceso de auditoría, nuestra SEO Expert App detecta la ausencia de cabeceras de seguridad y fallos de protocolo en segundos.

Preguntas Frecuentes (FAQ) sobre HSTS y Seguridad en 2026