CertH certH
Sur cette page

HSTS expliqué : max-age, preload et ce qui casse

Mis à jour le 2026-11-03 · 6 min de lecture

HSTS est le seul en-tête de sécurité qui peut rendre un site inaccessible — y compris pour son propriétaire. Il est aussi exigé pour un A+. L’écart entre ces deux faits tient entièrement à la discipline du déploiement.

Ce que fait réellement l’en-tête

Strict-Transport-Security indique au navigateur que cet hôte ne doit être contacté que via HTTPS pendant les N prochaines secondes. Une fois reçu, le navigateur réécrit les liens http:// internes, bloque le clic de contournement d’erreur de certificat et refuse le HTTP en clair — avant même qu’une requête ne quitte la machine.

C’est pourquoi il protège contre les attaques de rétrogradation qu’une redirection ne peut pas arrêter : une redirection envoie encore la première requête en clair, et c’est précisément la requête qu’un attaquant sur le réseau veut intercepter.

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

max-age est un compte à rebours que vous ne pouvez pas annuler

Le max-age est stocké côté client. Si vous servez un an puis retirez l’en-tête, chaque navigateur qui l’a vu continue d’imposer HTTPS pendant jusqu’à un an. Il n’existe aucun interrupteur côté serveur pour l’arrêter.

CertH considère 180 jours (15552000 secondes) comme le seuil pour A+. Un an est la valeur de production habituelle. En dessous de 180 jours, HSTS reste compté comme activé dans le résumé, mais ne débloque pas A+.

includeSubDomains et preload sont deux décisions distinctes

includeSubDomains étend la règle à chaque sous-domaine. Si un seul sous-domaine ne parle que HTTP — un outil interne, un panneau d’administration hérité, un hôte de staging —, il devient inaccessible pour quiconque a visité le domaine parent. Auditez le DNS d’abord.

Preload va plus loin : le domaine est inscrit dans une liste livrée avec les navigateurs, la règle s’applique donc dès la première visite, avant même qu’un en-tête ne soit vu. Le retrait prend des mois et nécessite une soumission à la liste de retrait. N’ajoutez pas preload avant que l’en-tête soit stable depuis au moins quelques mois.

  • •Servir l’en-tête sur chaque réponse HTTPS, y compris les pages d’erreur — un 404 sans lui n’apprend rien au navigateur.
  • •Ne jamais envoyer HSTS sur du HTTP en clair ; les navigateurs l’ignorent par spécification, une boucle de redirection mal configurée ne peut donc pas être corrigée ainsi.
  • •Vérifier les sous-domaines pour des services HTTP avant d’ajouter includeSubDomains.
  • •Ajouter preload en dernier, et seulement après que le max-age est à un an depuis un moment.

Un déploiement qui ne casse rien

Commencez par un max-age court pour qu’une erreur expire vite : max-age=300. Gardez-le une semaine et surveillez les sous-domaines cassés et les rapports de contenu mixte. Passez ensuite à un jour, puis un mois, puis un an. Chaque étape est réversible dans la fenêtre précédente, c’est tout l’intérêt de commencer court.

Si quelque chose casse, la solution est de servir correctement HTTPS sur l’hôte concerné — pas de retirer l’en-tête, ce qui n’aide plus personne ayant déjà reçu l’en-tête.

FAQ

L’absence de HSTS fait-elle baisser mon score ?

Elle ne retire pas de points de base, mais elle bloque A+ : la meilleure note exige un HSTS avec au moins 180 jours de max-age ou un preload. Un site peut obtenir 100 et rester un A sans HSTS.

Puis-je utiliser HSTS sans posséder tous les sous-domaines ?

Oui, tant que vous omettez includeSubDomains. L’en-tête ne s’applique alors qu’à l’hôte exact qui l’a servi.

À lire ensuite