Strict-Transport-Security
Uso
La cabecera Strict-Transport-Security es el mecanismo que hay detrás de HTTP Strict Transport Security (HSTS). Cuando un navegador recibe esta cabecera a través de una conexión segura, registra la directiva y actualiza automáticamente a HTTPS todas las solicitudes HTTP futuras dirigidas al dominio indicado. Si la conexión segura no está disponible, el navegador deniega el acceso por completo en lugar de recurrir a HTTP sin cifrar.
Esta cabecera solo se respeta cuando se entrega a través de HTTPS. Una respuesta servida por HTTP sin cifrar que contenga Strict-Transport-Security se ignora, porque un atacante situado en la ruta de red podría inyectar o modificar la cabecera.
La cabecera acepta tres directivas: max-age, includeSubDomains y preload.
max-age
La directiva max-age es obligatoria. Su valor especifica el número de segundos durante los cuales el navegador recuerda que debe exigir HTTPS para el dominio. Un valor habitual en producción es 63072000 (dos años). Establecer max-age=0 borra de inmediato la entrada HSTS de la caché del navegador.
includeSubDomains
La directiva includeSubDomains extiende la exigencia de HTTPS a todos los subdominios del host. Sin esta directiva, HSTS se aplica únicamente al dominio exacto que figura en la respuesta. Añadir includeSubDomains evita que un atacante aproveche un subdominio en HTTP sin cifrar para establecer cookies o redirigir el tráfico.
preload
La directiva preload no forma parte de la especificación de HSTS. Los fabricantes de navegadores mantienen listas de precarga de HSTS, y la directiva preload indica la intención del propietario del dominio de ser incluido. Una vez que un dominio aparece en una lista de precarga, los navegadores exigen HTTPS desde la primera conexión, lo que elimina la ventana de vulnerabilidad previa a la recepción de la primera cabecera Strict-Transport-Security. Enviar un dominio a la lista de precarga requiere un max-age de al menos un año (31536000 segundos) y la directiva includeSubDomains.
Ejemplo
Un servidor que exige HTTPS durante dos años en todos los subdominios y es apto para la precarga:
Strict-Transport-Security: max-age=63072000; includeSubDomains; preloadUna configuración mínima que establece HSTS durante seis meses solo en el dominio principal:
Strict-Transport-Security: max-age=15768000Borrado de la entrada HSTS restableciendo max-age a cero, útil durante migraciones o pruebas:
Strict-Transport-Security: max-age=0Diagnóstico
Los problemas de HSTS suelen manifestarse como fallos de conexión o bucles de redirección que persisten incluso después de cambiar la configuración del servidor, porque el navegador almacena la política en caché localmente.
Quedarse fuera tras habilitar HSTS con un max-age prolongado. Una vez que un navegador registra la política HSTS, todas las solicitudes se actualizan automáticamente a HTTPS. No es posible volver a HTTP hasta que max-age expire o el usuario borre manualmente la entrada HSTS. En Chrome, abra chrome://net-internals/#hsts, introduzca el dominio en “Delete domain security policies” y elimine la entrada. En Firefox, cierre el navegador, edite SiteSecurityServiceState.txt en la carpeta del perfil y elimine la línea del dominio.
Fallos en subdominios provocados por includeSubDomains. Añadir includeSubDomains fuerza HTTPS en todos los subdominios, incluidas herramientas internas, servidores de preproducción y servicios heredados que carecen de un certificado válido. Verifique que cada subdominio sirva un certificado TLS de confianza antes de habilitar esta directiva. Si un subdominio deja de funcionar, elimine includeSubDomains y vuelva a desplegar la cabecera con max-age=0 para borrar las entradas almacenadas en caché.
La eliminación de la lista de precarga tarda meses. La lista de precarga de HSTS se distribuye con las versiones de los navegadores, por lo que la eliminación requiere enviar una solicitud en hstspreload.org, esperar la siguiente actualización de la lista y esperar a que esa actualización llegue a los usuarios mediante las actualizaciones de versión del navegador. Este proceso tarda varios meses. Considere preload como un compromiso a largo plazo y verifique que todo esté listo para HTTPS antes de enviar la solicitud.
La cabecera HSTS enviada por HTTP sin cifrar se ignora. Los navegadores descartan la cabecera Strict-Transport-Security cuando la respuesta llega por una conexión no cifrada. La cabecera solo surte efecto en respuestas HTTPS. Confirme que la cabecera está presente en la respuesta HTTPS comprobándolo con: curl -sI https://example.re | grep -i strict.
Errores de contenido mixto después de habilitar HSTS. HSTS actualiza la página a HTTPS, pero los recursos incrustados que siguen haciendo referencia a URL http:// provocan advertencias o bloqueos por contenido mixto. Revise todas las URL de recursos (imágenes, scripts, hojas de estilo, endpoints de API) y actualice las referencias para que usen https:// o rutas relativas al protocolo. La directiva de CSP upgrade-insecure-requests se encarga de esto automáticamente para las URL HTTP codificadas de forma fija que queden.
El fallo en la renovación del certificado deja todo el sitio inaccesible. Un certificado caducado o no válido en un dominio protegido por HSTS provoca un fallo irrecuperable que el usuario no puede eludir. Los navegadores se niegan a mostrar el sitio y no ofrecen la opción de “continuar de todos modos”. Automatice la renovación del certificado (certbot de Let’s Encrypt lo gestiona con una tarea cron) y supervise las fechas de caducidad de los certificados. Configure alertas con al menos 14 días de antelación respecto a la caducidad.