Strict-Transport-Security

Utilisation

L’en-tête Strict-Transport-Security est le mécanisme qui sous-tend HTTP Strict Transport Security (HSTS). Lorsqu’un navigateur reçoit cet en-tête sur une connexion sécurisée, il enregistre la directive et bascule automatiquement vers HTTPS toutes les futures requêtes HTTP destinées au domaine indiqué. Si la connexion sécurisée est indisponible, le navigateur refuse purement et simplement l’accès au lieu de se rabattre sur HTTP en clair.

Cet en-tête n’est pris en compte que lorsqu’il est transmis via HTTPS. Une réponse servie en HTTP en clair contenant Strict-Transport-Security est ignorée, car un attaquant présent sur le chemin réseau serait en mesure d’injecter ou de modifier l’en-tête.

L’en-tête accepte trois directives : max-age, includeSubDomains et preload.

max-age

La directive max-age est obligatoire. Sa valeur indique le nombre de secondes pendant lesquelles le navigateur se souvient d’imposer HTTPS pour le domaine. Une valeur courante en production est 63072000 (deux ans). Définir max-age=0 efface immédiatement l’entrée HSTS du cache du navigateur.

includeSubDomains

La directive includeSubDomains étend l’application de HTTPS à chaque sous-domaine de l’hôte. Sans cette directive, HSTS ne s’applique qu’au domaine exact figurant dans la réponse. Ajouter includeSubDomains empêche un attaquant d’exploiter un sous-domaine en HTTP en clair pour déposer des cookies ou rediriger le trafic.

preload

La directive preload ne fait pas partie de la spécification HSTS. Les éditeurs de navigateurs maintiennent des listes de préchargement HSTS, et la directive preload signale l’intention du propriétaire du domaine d’y figurer. Dès qu’un domaine apparaît sur une liste de préchargement, les navigateurs imposent HTTPS dès la première connexion, ce qui élimine la fenêtre de vulnérabilité précédant la réception du premier en-tête Strict-Transport-Security. Soumettre un domaine à la liste de préchargement exige un max-age d’au moins un an (31536000 secondes) ainsi que la directive includeSubDomains.

Exemple

Un serveur imposant HTTPS pendant deux ans sur l’ensemble des sous-domaines, avec éligibilité au préchargement :

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

Une configuration minimale appliquant HSTS pendant six mois au domaine principal uniquement :

Strict-Transport-Security: max-age=15768000

Effacement de l’entrée HSTS en remettant max-age à zéro, utile lors des migrations ou des phases de test :

Strict-Transport-Security: max-age=0

Dépannage

Les problèmes liés à HSTS se manifestent généralement par des échecs de connexion ou des boucles de redirection qui persistent même après une modification du serveur, car le navigateur met la politique en cache localement.

Blocage total après l’activation de HSTS avec un max-age élevé. Une fois que le navigateur a enregistré la politique HSTS, toutes les requêtes sont automatiquement basculées en HTTPS. Revenir à HTTP est impossible tant que le max-age n’a pas expiré ou que l’utilisateur n’a pas supprimé manuellement l’entrée HSTS. Dans Chrome, ouvrez chrome://net-internals/#hsts, saisissez le domaine sous « Delete domain security policies », puis supprimez l’entrée. Dans Firefox, fermez le navigateur, modifiez SiteSecurityServiceState.txt dans le dossier du profil et supprimez la ligne correspondant au domaine.

Sous-domaines cassés par includeSubDomains. Ajouter includeSubDomains impose HTTPS sur chaque sous-domaine, y compris les outils internes, les serveurs de préproduction et les services hérités dépourvus de certificat valide. Vérifiez que chaque sous-domaine présente un certificat TLS de confiance avant d’activer cette directive. Si un sous-domaine cesse de fonctionner, retirez includeSubDomains et redéployez l’en-tête avec max-age=0 afin d’effacer les entrées en cache.

Retrait de la liste de préchargement en plusieurs mois. La liste de préchargement HSTS est livrée avec les versions des navigateurs : son retrait suppose donc de soumettre une demande sur hstspreload.org, d’attendre la mise à jour suivante de la liste, puis d’attendre que cette mise à jour atteigne les utilisateurs via les montées de version des navigateurs. Ce processus prend plusieurs mois. Considérez preload comme un engagement de long terme et vérifiez que le passage intégral à HTTPS est prêt avant toute soumission.

Un en-tête HSTS envoyé en HTTP en clair est ignoré. Les navigateurs écartent l’en-tête Strict-Transport-Security lorsque la réponse arrive sur une connexion non chiffrée. L’en-tête ne prend effet que sur les réponses HTTPS. Vérifiez la présence de l’en-tête sur la réponse HTTPS à l’aide de : curl -sI https://example.re | grep -i strict.

Erreurs de contenu mixte après l’activation de HSTS. HSTS bascule la page en HTTPS, mais les ressources intégrées qui référencent encore des URL http:// déclenchent des avertissements ou des blocages pour contenu mixte. Auditez toutes les URL de ressources (images, scripts, feuilles de style, points de terminaison d’API) et mettez à jour les références pour utiliser https:// ou des chemins relatifs au protocole. La directive CSP upgrade-insecure-requests traite ce cas automatiquement pour les URL HTTP restées codées en dur.

Échec de renouvellement de certificat entraînant le blocage complet du site. Un certificat expiré ou invalide sur un domaine protégé par HSTS provoque un échec bloquant, sans possibilité de contournement par l’utilisateur. Les navigateurs refusent d’afficher le site et ne proposent pas d’option « continuer malgré tout ». Automatisez le renouvellement des certificats (le certbot de Let’s Encrypt s’en charge via une tâche cron) et surveillez les dates d’expiration. Configurez des alertes au moins 14 jours avant l’expiration.