Guide de correction

Configurer HSTS sans bloquer vos visiteurs

Par Antoine Le Louët · Lecture estimée : 6 min · Références

HSTS demande au navigateur de revenir en HTTPS. Une erreur peut rester mémorisée : commencez par vérifier les hôtes concernés et choisissez une durée courte.

Protéger les prochaines connexions

Strict-Transport-Security est un en-tête reçu via HTTPS valide. Le navigateur mémorise la règle pendant max-age secondes et convertit ensuite les accès HTTP vers HTTPS. Il n’autorise plus le contournement d’une erreur de certificat pour cet hôte.

Sans règle mémorisée ni préchargement, la toute première visite HTTP reste exposée. Une redirection HTTP vers HTTPS reste nécessaire. HSTS ne corrige ni un certificat invalide, ni une faille applicative, ni la sécurité du contenu.

Vérifier le périmètre HTTPS

Utilisez des hôtes que vous administrez. Vérifiez certificat, renouvellement, redirections et ressources HTTPS pour les pages principales, les erreurs et les services annexes. Inventoriez les sous-domaines, y compris les anciens services et ceux gérés par un tiers.

Ces commandes utilisent GET sans télécharger le corps et sans désactiver la validation TLS. Lisez chaque réponse de redirection et la réponse finale ; ne concluez pas à partir de HEAD seulement.

curl -sS -D - -o /dev/null http://example.com/
curl -sS -L -D - -o /dev/null https://example.com/
curl -sS -D - -o /dev/null https://app.example.com/

Augmenter max-age par étapes

Exemple initial pour un hôte déjà opérationnel en HTTPS : une règle de 300 secondes, sans sous-domaines ni preload. Placez-la sur les réponses HTTPS du serveur ou du proxy responsable, puis vérifiez l’en-tête réellement reçu.

Strict-Transport-Security: max-age=300
  1. Tester navigation, certificats et renouvellement pendant cette phase courte.
  2. Si le service reste fiable, passer par exemple à 86400 secondes (un jour), puis augmenter selon votre capacité à maintenir HTTPS.
  3. Surveiller les erreurs avant chaque hausse. Une durée longue engage aussi les visiteurs qui ne reviennent pas pendant votre correction.

includeSubDomains et preload : deux engagements

includeSubDomains couvre tous les descendants de l’hôte qui porte la règle, y compris ceux ajoutés plus tard. Ne l’ajoutez qu’après validation HTTPS de ce périmètre. Une règle reçue sur www.example.com ne protège pas automatiquement example.com.

preload n’est pas recommandé par défaut. Le jeton seul n’inscrit pas un domaine : une soumission et les critères de la liste sont nécessaires, notamment HTTPS pour tous les sous-domaines et un max-age d’au moins un an avec includeSubDomains. Le retrait et sa propagation dans les navigateurs prennent du temps.

Préparer un retour arrière

max-age=0 envoyé en HTTPS valide supprime la règle dynamique de cet hôte quand le navigateur le reçoit. Cela n’efface ni une règle héritée d’un parent, ni les règles propres des sous-domaines, ni une entrée préchargée. Retirer simplement l’en-tête laisse les règles déjà mémorisées expirer naturellement.

Maintenez HTTPS pendant la transition. Les visiteurs bloqués par un certificat invalide ne pourront pas recevoir votre en-tête correctif.

Vérifier le résultat avec Argos

http.security.hsts vérifie un max-age positif reconnu et le contexte HTTPS de la réponse finale. Des constats TLS externes peuvent le compléter. Cette heuristique ne prouve ni une durée adaptée, ni la couverture des sous-domaines, ni l’inscription effective dans la liste preload.

Après vos contrôles de périmètre, relancez un audit de la page. Comparez l’URL finale et les preuves ; une mesure sur une URL ne valide pas tous vos hôtes. Consultez aussi le guide CSP pour les règles de chargement du contenu.

Références officielles

Références consultées le 16 octobre 2026. Exemples à adapter et à tester sur votre périmètre.

Vérifier votre correction

Après vos tests, relancez un audit de la même URL publique et comparez les constats disponibles.

Lancer un nouvel audit