HSTS : ce qu'il protège, ce qu'il engage

La requête que la redirection ne protège pas

La plupart des sites redirigent l'adresse en « http » vers l'adresse en « https ». La redirection ramène le visiteur au bon endroit, mais sa première requête est déjà partie en clair. Sur un réseau partagé, un Wi-Fi public par exemple, celui qui contrôle le réseau peut répondre à ce moment-là à la place de votre serveur, et garder le visiteur sur une version en clair.

La RFC 6797, qui définit HSTS depuis 2012, décrit précisément ce cas : le visiteur tape l'adresse, ou suit un lien, en « http ». Les cookies partent avec cette première requête s'ils n'ont pas l'attribut Secure, présenté dans le guide sur les cookies sécurisés.

L'en-tête a un second effet, moins connu. Sur un site qui l'a envoyé, le navigateur ne propose plus de passer outre une erreur de certificat : la RFC demande qu'il n'offre aucun recours à l'utilisateur. La page ne s'ouvre pas.

Il reste une limite. Le navigateur n'apprend la règle qu'en recevant l'en-tête une première fois en HTTPS, et un en-tête reçu en clair est ignoré. La toute première visite n'est donc pas couverte, sauf par le préchargement.

max-age, includeSubDomains, preload : ce que règle chaque directive

L'en-tête tient en une ligne, et chacune de ses directives engage autre chose.

• max-age fixe, en secondes, la durée pendant laquelle le navigateur retient la règle. Chaque réponse qui porte l'en-tête la renouvelle. Une valeur nulle demande au navigateur d'oublier la règle, et une durée de quelques minutes laisse repartir en clair le visiteur qui revient le lendemain.
• includeSubDomains étend la règle à tous les sous-domaines : la boutique, le blog, l'extranet, et ceux dont plus personne ne se souvient.
• preload n'est pas défini par la RFC. Cette directive signale que le domaine accepte d'être inscrit sur la liste de préchargement tenue par le projet Chromium, livrée avec le navigateur : le domaine y est traité en HTTPS avant même la première visite. Firefox, Safari et Edge utilisent des listes fondées sur celle-ci.

L'inscription sur la liste exige une durée d'au moins un an, includeSubDomains, et HTTPS sur tous les sous-domaines.

Ce qui casse, et pourquoi on ne revient pas vite en arrière

Avec includeSubDomains, un sous-domaine resté en HTTP devient inaccessible à tout visiteur déjà passé par votre site : un ancien extranet, un outil interne, une adresse de test, un service tiers branché sur un de vos sous-domaines. Le visiteur voit une erreur, sans bouton pour continuer.

Un certificat expiré a le même effet sur le domaine principal. Là où le visiteur pouvait autrefois accepter l'alerte et entrer, la page ne s'ouvre plus du tout.

Revenir en arrière prend du temps. Le navigateur applique la règle jusqu'au terme de max-age, et il ne voit une valeur plus courte qu'en revenant sur le site. Pour la liste de préchargement, son site officiel prévient qu'un retrait met des mois à atteindre les utilisateurs, et demande de ne s'inscrire que si HTTPS est tenu durablement sur tout le domaine et tous ses sous-domaines.

L'agence nationale de la sécurité des systèmes d'information (ANSSI) pose la même condition. Dans ses recommandations pour la mise en œuvre d'un site web, HSTS est la recommandation R2, avec cet avertissement : « la pérennité de l'accès en HTTPS est un prérequis indispensable à HSTS ».

Ce que nous relevons sur les sites audités

Ce pourcentage porte sur une trentaine de sites audités entre le 14 août 2026 et le 24 septembre 2026, ceux où le point a pu être vérifié. Beaucoup ont été audités parce qu'un défaut s'y voyait vite : le chiffre décrit nos audits, pas l'ensemble des sites.

Ce que l'audit regarde

L'audit lit l'en-tête sur la réponse en HTTPS de votre site, telle qu'un navigateur la reçoit. Le rapport en donne la valeur servie : la durée demandée, et la présence de includeSubDomains et de preload. L'absence de l'en-tête retire un nombre fixe de points à la note du pilier.

La redirection de l'adresse en clair est mesurée à part, parce que les deux ne font pas la même chose : la redirection ramène le visiteur vers HTTPS, HSTS évite que sa requête parte en clair. Un site peut avoir l'une sans l'autre. Un serveur qui ne répond pas du tout en clair n'est pas pénalisé, puisqu'il ne sert aucune page en clair.

Ce qui se règle simplement, ce qui se prépare

Quand tous vos sous-domaines servent HTTPS, l'en-tête est un réglage unique, chez l'hébergeur, dans le service placé devant le serveur ou dans une extension du CMS.

Ce qui se prépare, c'est l'inventaire : tous vos sous-domaines, y compris ceux qui ne servent plus ou que gère un prestataire. La prudence veut une durée courte d'abord, allongée une fois l'inventaire vérifié, et le préchargement en dernier, seulement si HTTPS est tenu dans la durée.

HSTS est présenté avec les autres en-têtes de protection dans le guide sur les en-têtes de sécurité HTTP. Côté nom de domaine, DNSSEC protège une autre étape : la réponse qui indique à quel serveur se connecter.

Ce que cette vérification ne dit pas

Par Quentin Mathis, Z29K · mis à jour le 28 septembre 2026