HSTS (HTTP Strict Transport Security): qué es y cómo funciona

HSTS (HTTP Strict Transport Security) es una política de seguridad que un sitio declara con la cabecera de respuesta Strict-Transport-Security. Una vez que un navegador la ha visto en una conexión HTTPS válida, se niega a usar HTTP plano con ese host hasta que la política caduque: los enlaces http:// escritos a mano se actualizan internamente antes de que salga ninguna petición del dispositivo, y los errores de certificado ya no se pueden saltar con un clic. El mecanismo se define en la RFC 6797.

La cabecera

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

• max-age: durante cuánto tiempo, en segundos, debe recordar el navegador la política (31536000 = un año).
• includeSubDomains: aplica la política también a todos los subdominios.
• preload: indica tu consentimiento para entrar en la lista de precarga integrada de los navegadores. No forma parte de la RFC; lo usa la lista de precarga de HSTS que mantiene el proyecto Chromium y comparten otros navegadores importantes.

En Nginx, envíala solo en las respuestas HTTPS:

server {
    listen 443 ssl;
    server_name www.example.com;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}

Por qué importa

Sin HSTS, un visitante que escribe example.com hace una primera petición por HTTP y depende de tu redirección 301 para llegar a HTTPS. En una red hostil, esa primera petición sin cifrar puede interceptarse y mantener al usuario en una versión HTTP falsa: es un ataque de SSL stripping. HSTS cierra esa brecha para los visitantes que vuelven, y la lista de precarga la cierra también en la primera visita.

Hay un beneficio de rendimiento: para los navegadores compatibles con HSTS desaparece el salto de HTTP a HTTPS, porque el propio navegador actualiza la URL (las herramientas para desarrolladores lo muestran como una redirección 307 interna). HSTS no es un factor de posicionamiento, pero completa una configuración HTTPS limpia, que Google y los usuarios ya esperan.

Cómo desplegarlo sin riesgos

1. Confirma que todas las páginas y subdominios funcionan por HTTPS con un certificado válido.
2. Empieza con un max-age corto, como 300 segundos, y vigila los problemas.
3. Auméntalo a una semana, a un mes y luego a un año.
4. Añade includeSubDomains solo cuando todos los subdominios (incluidos los antiguos entornos de pruebas, el correo y las herramientas de intranet) admitan HTTPS.
5. Solicita la precarga al final, y solo si estás seguro. La lista de precarga exige un max-age de al menos un año, includeSubDomains y preload, y la retirada tarda meses en llegar a los navegadores de los usuarios.

Errores habituales

• Enviar la cabecera por HTTP, donde los navegadores la ignoran por diseño.
• Precargar un dominio mientras sigue existiendo un subdominio solo HTTP, que pasa a ser inaccesible en los navegadores.
• Fijar un max-age largo antes de que HTTPS sea estable, lo que deja fuera a los visitantes si el certificado falla.
• Suponer que HSTS sustituye a la redirección del servidor. Mantén la redirección para los visitantes que llegan por primera vez, los rastreadores y los clientes que no admiten HSTS.

Cómo comprobarlo

El Cabeceras de seguridad puntúa tu cabecera Strict-Transport-Security junto con las demás cabeceras de seguridad y ofrece correcciones para copiar y pegar en Apache, Nginx y Cloudflare. El Comprobador SSL confirma el certificado y la redirección de HTTP a HTTPS de los que depende HSTS.

Preguntas frecuentes