Aller au contenu
DomainVigil
S'inscrire

Guide de référence

Qu'est-ce que HSTS ?

HSTS est une phrase que votre serveur dit au navigateur : à partir de maintenant, et pour un an, tu refuses de me joindre autrement qu'en HTTPS. Elle est très efficace, et très difficile à retirer.

8 min de lectureMis à jour le 12 septembre 2026

En bref

HSTS est un en-tête HTTP qui demande au navigateur de ne plus jamais joindre un site en HTTP pendant une durée donnée. Une fois reçu, il est mémorisé côté navigateur : même si le visiteur tape une adresse en HTTP, la requête part en HTTPS sans jamais quitter sa machine. L'en-tête n'est pris en compte que s'il arrive sur une connexion HTTPS valide.

À quoi sert HSTS

Rediriger le HTTP vers le HTTPS ne suffit pas. Entre le moment où le visiteur tape votre adresse et celui où la redirection lui parvient, une première requête est partie en clair sur le réseau. C'est là qu'une interception est possible : il suffit de répondre à la place du site et de ne jamais laisser la redirection arriver.

HSTS ferme cette fenêtre pour toutes les visites suivantes. Le navigateur mémorise la consigne et réécrit lui-même l'adresse avant d'ouvrir la moindre connexion : plus rien ne part en clair, même si le visiteur clique sur un vieux lien en HTTP. Il refuse aussi de laisser passer un avertissement de certificat, là où il proposerait normalement de continuer.

Le revers est proportionnel. Une consigne d'un an est une promesse d'un an, mémorisée sur les machines de vos visiteurs, que vous ne pouvez pas révoquer à distance. Un site qui casse son HTTPS après avoir posé HSTS devient inaccessible, sans porte de secours, pour tous ceux qui sont déjà venus.

L'en-tête, terme par terme

Une seule ligne, envoyée avec chaque réponse HTTPS du site. Sa place compte autant que son contenu.

HTTP/2 200 content-type: text/html; charset=utf-8 strict-transport-security: max-age=31536000; includeSubDomains; preload

  1. strict-transport-securityLe nom de l'en-tête

    Il n'est pris en compte que sur une réponse servie en HTTPS et sans erreur de certificat. Envoyé sur une réponse en clair, il est ignoré — c'est la cause numéro un des mises en place qui ne font rien.

  2. max-age=31536000La durée, en secondes

    Obligatoire. Ici un an. Le compteur repart à zéro à chaque visite, ce qui fait qu'un visiteur régulier reste couvert en permanence.

  3. includeSubDomainsL'extension à tous les sous-domaines

    Applique la règle à tout ce qui se trouve sous le nom, y compris aux sous-domaines créés plus tard. C'est la directive qui rend un outil interne encore servi en HTTP brusquement inaccessible.

  4. preloadLa demande d'inscription à la liste embarquée

    Ne fait rien par elle-même : elle signale que vous acceptez de figurer dans la liste livrée avec les navigateurs. L'inscription, elle, se demande séparément.

Les directives HSTS et leurs effets

Une directive obligatoire, deux facultatives, et deux règles de comportement qu'on ne trouve pas dans les tutoriels mais qui expliquent la plupart des déploiements sans effet.

DirectiveCe qu'elle faitÀ savoir
max-age=31536000Fixe la durée pendant laquelle le navigateur refusera le HTTP pour ce nom. Un an ici.Obligatoire. Sans elle, l'en-tête entier est ignoré.
max-age=0Efface la consigne mémorisée pour ce nom.La seule marche arrière possible, et elle ne s'applique qu'aux visiteurs qui reviennent voir la nouvelle réponse.
includeSubDomainsÉtend la règle à tous les sous-domaines, présents et futurs.À n'activer qu'après inventaire complet : un seul sous-domaine encore en HTTP devient injoignable.
preloadDéclare que vous demandez l'inscription à la liste embarquée dans les navigateurs.Ne figure pas dans la norme : c'est une exigence des navigateurs, pas du protocole.
En-tête reçu en HTTP simpleRien : le navigateur l'ignore entièrement.Le poser sur la réponse de redirection est sans effet. Il doit être sur la réponse HTTPS.
En-tête reçu avec un certificat invalideRien non plus : la consigne n'est pas enregistrée.Un certificat cassé empêche donc à la fois de poser HSTS et, s'il était déjà posé, de joindre le site.

Vérifiez sur votre domaine, tout de suite

Entrez un nom de domaine : l'outil lit son certificat, sa validité et l'autorité qui l'a émis — le socle sans lequel HSTS ne sert à rien.

Sans inscription, sans e-mail à laisser. Vous pouvez coller une adresse complète : nous en extrayons le domaine.

L'escalier de déploiement

Poser un an d'emblée, c'est signer pour un an sans avoir testé. Les cinq marches se montent en quelques semaines, et chacune reste réversible tant qu'on n'a pas atteint la dernière.

  1. 1

    Servir tout le site en HTTPS

    Y compris les sous-domaines, les outils internes, les anciennes adresses et les images appelées depuis d'autres sites. C'est l'inventaire, et c'est l'étape la plus longue.

  2. 2

    Poser une durée très courte

    Cinq minutes. Si quelque chose casse, la consigne s'efface d'elle-même avant la fin de la réunion.

    max-age=300

  3. 3

    Monter à une journée, puis à une semaine

    Chaque palier laisse le temps de voir apparaître ce que l'inventaire avait manqué, sans engager la suite.

    max-age=86400 → max-age=604800

  4. 4

    Passer à un an

    La valeur de régime. À partir d'ici, un retour en arrière ne se fait plus en une journée : il faut servir une durée nulle et attendre que chaque visiteur revienne.

    max-age=31536000

  5. 5

    Étendre aux sous-domaines, puis demander la liste

    Ces deux dernières marches ne se montent que si l'on sait ce qu'on signe : la liste embarquée protège dès la toute première visite, et se quitte en plusieurs mois.

La liste embarquée : ce qu'elle exige, ce qu'elle coûte

HSTS ne protège pas la toute première visite d'un navigateur qui n'a jamais vu le site. La liste livrée avec les navigateurs règle ce cas — au prix d'un engagement qui ne se défait pas en un après-midi.

ConditionCe qu'elle exigePourquoi
Certificat valideUn certificat reconnu sur le domaine et sur tous ses sous-domaines.L'inscription suppose que le HTTPS fonctionne partout, sans exception.
Redirection depuis le HTTPLe HTTP du même nom doit rediriger vers le HTTPS du même nom.Une redirection vers un autre nom d'abord casse la vérification.
Sous-domaines en HTTPSTous, y compris ceux qui ne sont pas publics.L'inscription impose l'extension aux sous-domaines : ce qui reste en HTTP deviendra injoignable.
En-tête sur la racineUne durée d'au moins un an, l'extension aux sous-domaines, et le mot-clé d'inscription.C'est la preuve que l'engagement est assumé sur la durée, et pas seulement testé.
Le retraitUne demande, puis l'attente d'une nouvelle version de chaque navigateur.Comptez plusieurs mois avant que les appareils cessent d'appliquer la consigne. Il faut le savoir avant de s'inscrire, pas après.

Les erreurs de mise en place

  • L'en-tête est posé et il ne se passe rien

    Ce qui le provoque : Il est envoyé sur la réponse de redirection en clair, et non sur la réponse HTTPS. Le navigateur l'ignore, comme le veut la norme.

    Le geste qui corrige : Le poser sur les réponses servies en HTTPS. Vérifier depuis un outil qui montre les en-têtes réels, et non depuis la configuration du serveur.

  • Un sous-domaine devient brusquement inaccessible

    Ce qui le provoque : L'extension aux sous-domaines a été activée alors qu'un outil interne, une ancienne interface ou un service de développement était encore servi en HTTP.

    Le geste qui corrige : Retirer l'extension, faire l'inventaire complet des sous-domaines, les passer tous en HTTPS, puis réactiver. Pendant ce temps, les visiteurs déjà couverts restent bloqués.

  • On veut revenir en arrière et on ne peut pas

    Ce qui le provoque : La consigne d'un an est mémorisée sur les machines des visiteurs. Rien de ce que vous faites sur le serveur ne l'efface à distance.

    Le geste qui corrige : Servir une durée nulle en HTTPS et attendre que chaque visiteur revienne. Seuls ceux qui reviennent voient la nouvelle consigne — les autres restent sur l'ancienne jusqu'à son terme.

  • Le certificat expire et le site devient totalement inaccessible

    Ce qui le provoque : HSTS interdit au visiteur de passer outre l'avertissement de certificat. Ce qui serait normalement un écran d'alerte devient un mur.

    Le geste qui corrige : Traiter l'expiration du certificat comme une panne majeure dès lors que HSTS est actif, et surveiller la date depuis l'extérieur plutôt que sur le serveur.

Les questions qu'on se pose ensuite

HSTS remplace-t-il la redirection du HTTP vers le HTTPS ?

Non, il la complète. La redirection reste indispensable pour la toute première visite, celle où le navigateur n'a encore rien mémorisé. HSTS protège toutes les suivantes.

Quelle durée choisir ?

Un an en régime établi, mais jamais d'emblée. Montez par paliers : cinq minutes, une journée, une semaine, puis un an. Chaque palier vous laisse découvrir ce que l'inventaire avait oublié pendant qu'il est encore réversible.

Faut-il demander l'inscription à la liste embarquée ?

Seulement si le HTTPS est acquis partout et pour longtemps, sous-domaines compris. Le gain concerne uniquement la première visite d'un nouveau navigateur ; le coût est un engagement dont on ne sort qu'en plusieurs mois.

HSTS protège-t-il de tout ?

Non. Il garantit que la connexion se fait en HTTPS et qu'aucun avertissement ne peut être contourné. Il ne dit rien de ce que contient la page, ni de la validité réelle du certificat au-delà de sa reconnaissance par le système.

Avec HSTS, un certificat expiré n'est plus un avertissement

C'est un mur : le visiteur ne peut pas passer outre, et le site est purement et simplement inaccessible. DomainVigil surveille le certificat de chacun de vos domaines depuis l'extérieur et vous prévient bien avant l'échéance.

Commencer gratuitement

Cinq domaines gratuits, pour toujours. Sans carte bancaire.

Les autres guides de référence