HSTS a été normalisé en novembre 2012 par la RFC 6797. Son but est de fermer une brèche que la simple redirection de HTTP vers HTTPS laisse ouverte : tant qu’un visiteur tape exemple.fr sans préciser le protocole, son navigateur commence par une requête en clair. Sur un Wi-Fi public, un attaquant placé au milieu peut intercepter cette requête et garder la victime en HTTP, une attaque connue sous le nom de SSL stripping. Avec HSTS, le navigateur se souvient que le site exige HTTPS et ne tente même plus la version en clair.
Comment fonctionne HSTS
Le serveur ajoute l’en-tête Strict-Transport-Security à ses réponses HTTPS. Trois directives existent :
max-age(obligatoire) : durée, en secondes, pendant laquelle le navigateur retient la consigne ;includeSubDomains: applique la règle à tous les sous-domaines ;preload: signale que le domaine accepte d’être inscrit dans la liste de préchargement des navigateurs.
Strict-Transport-Security: max-age=31536000; includeSubDomains
La RFC impose deux comportements importants. D’abord, un navigateur ignore l’en-tête s’il arrive en HTTP, pour qu’un intermédiaire ne puisse ni l’ajouter ni l’effacer. Ensuite, sur un site HSTS, toute erreur de certificat TLS coupe la connexion : l’utilisateur n’a plus de bouton pour « continuer quand même ».

La première visite et le préchargement
HSTS a une faiblesse reconnue par MDN comme par la RFC : il ne s’applique qu’après une première connexion sécurisée réussie. Pour la combler, Chrome tient une liste de domaines codée dans le navigateur, sur laquelle s’appuient aussi Firefox, Safari et Edge. Le site hstspreload.org exige un certificat valide, une redirection de HTTP vers HTTPS, tous les sous-domaines en HTTPS et un en-tête avec max-age d’au moins 31536000 secondes (un an), includeSubDomains et preload. Il prévient que l’inscription s’annule difficilement et que le retrait met des mois à atteindre les utilisateurs.
Pour WordPress
WordPress n’envoie pas HSTS lui-même. Avant de l’activer, vérifiez que tout le site fonctionne en HTTPS : adresses dans Réglages, Général, contenu mixte corrigé, renouvellement automatique du certificat (souvent assuré par Let’s Encrypt chez l’hébergeur). Notre guide HTTPS sur WordPress déroule ces étapes.
- Commencez avec un
max-agecourt (300 secondes, puis une semaine), sansincludeSubDomains. - Contrôlez chaque sous-domaine (messagerie web, préproduction, extranet) avant d’ajouter
includeSubDomains. - Montez à un an quand tout est stable ; ne demandez le préchargement qu’en dernier.
- Posez l’en-tête à un seul endroit (serveur, CDN ou extension) pour éviter deux valeurs contradictoires.
HSTS fait partie des en-têtes de sécurité que vérifient les outils d’audit. Son effet sur le référencement est indirect, comme l’explique l’article HTTPS, HSTS et ce que Google prend vraiment en compte.
Erreurs fréquentes
- Activer un an d’HSTS avec
includeSubDomainsalors qu’un sous-domaine reste en HTTP : il devient inaccessible pour les visiteurs qui ont reçu l’en-tête. - Penser pouvoir revenir en arrière en coupant l’option : pour désactiver HSTS, il faut envoyer
max-age=0en HTTPS, ce qui suppose un certificat encore valide. - Laisser expirer le certificat : avec HSTS, le visiteur ne peut plus contourner l’alerte.
WP Masquerade Pro propose HSTS en option dans sa carte En-têtes de sécurité, avec un an de max-age, jamais envoyé en HTTP. L’interface rappelle que l’en-tête reste mémorisé par les navigateurs même après désactivation : ne l’activez que sur un site durablement en HTTPS.