HSTS (HTTP Strict Transport Security)

Le HSTS (HTTP Strict Transport Security) est un mécanisme de sécurité web qui permet à un serveur d’indiquer aux navigateurs qu’ils doivent obligatoirement se connecter en HTTPS pour toutes les requêtes futures, sans jamais tenter de connexion HTTP. Il se configure via un en-tête de réponse HTTP (Strict-Transport-Security) qui indique au navigateur de mémoriser cette instruction pendant une durée définie. En SEO, le HSTS élimine la redirection 301 HTTP → HTTPS après la première visite, ce qui réduit le TTFB, améliore le LCP et supprime une fenêtre de vulnérabilité lors de la connexion initiale. C’est le complément technique indispensable de la migration HTTPS pour garantir à la fois la sécurité et la performance.

Fonctionnement

Sans HSTS, lorsqu’un utilisateur tape mondomaine.fr dans sa barre d’adresse (sans spécifier le protocole), le navigateur envoie d’abord une requête HTTP. Le serveur répond par une redirection 301 vers la version HTTPS. Cette redirection ajoute un aller-retour réseau supplémentaire (un RTT) qui ralentit le chargement et crée une fenêtre de vulnérabilité pendant laquelle un attaquant pourrait intercepter la requête HTTP non chiffrée (SSL stripping).

Avec HSTS activé, le serveur inclut l’en-tête suivant dans ses réponses HTTPS :

Lorsque le navigateur reçoit cet en-tête, il mémorise que ce domaine ne doit être contacté qu’en HTTPS pendant la durée spécifiée par max-age (ici 31 536 000 secondes, soit un an). Pour toutes les visites suivantes, le navigateur convertit automatiquement toute requête HTTP en HTTPS côté client, sans contacter le serveur. La redirection 301 est éliminée, le RTT supplémentaire disparaît et la connexion est sécurisée dès le premier octet transmis.

Paramètres de l’en-tête

max-age définit la durée en secondes pendant laquelle le navigateur doit appliquer la politique HSTS. La valeur recommandée pour la production est de 31536000 (un an) ou 63072000 (deux ans). Une valeur plus courte (par exemple 300 secondes) est utilisée pendant la phase de test pour pouvoir revenir en arrière rapidement en cas de problème.

includeSubDomains étend la politique HSTS à tous les sous-domaines du domaine principal. Si l’en-tête est servi par mondomaine.fr avec includeSubDomains, les navigateurs appliqueront également le HTTPS forcé pour blog.mondomaine.fr, shop.mondomaine.fr et tout autre sous-domaine. Ce paramètre est requis pour l’inscription dans la liste HSTS Preload. Il ne doit être activé que lorsque tous les sous-domaines du site sont correctement configurés en HTTPS, sous peine de rendre inaccessibles les sous-domaines encore en HTTP.

preload est un paramètre non standard (non défini dans la RFC 6797) qui indique que le propriétaire du domaine souhaite l’inscrire dans la liste HSTS Preload maintenue par les navigateurs. Ce paramètre seul ne suffit pas : l’inscription doit être soumise manuellement sur le site hstspreload.org.

HSTS Preload

Le HSTS classique présente une limitation : lors de la toute première visite d’un utilisateur (avant que le navigateur ait reçu l’en-tête HSTS), la connexion passe toujours par HTTP avant d’être redirigée vers HTTPS. Cette première visite reste vulnérable au SSL stripping.

La liste HSTS Preload résout ce problème. C’est une liste de domaines maintenue par le projet Chromium et embarquée directement dans le code source des navigateurs (Chrome, Firefox, Safari, Edge, Opera). Les domaines inscrits dans cette liste sont toujours contactés en HTTPS, même lors de la première visite, car le navigateur connaît la politique HSTS du domaine avant toute connexion réseau.

Les conditions d’inscription sur la liste Preload sont les suivantes. Le domaine doit servir un certificat HTTPS valide. L’en-tête HSTS doit être présent avec un max-age d’au moins 31536000 (un an). Le paramètre includeSubDomains doit être activé. Le paramètre preload doit être présent dans l’en-tête. Toutes les redirections HTTP doivent pointer vers HTTPS. Tous les sous-domaines doivent être accessibles en HTTPS.

L’inscription dans la liste Preload est un processus difficilement réversible. La suppression d’un domaine de la liste peut prendre plusieurs mois car elle dépend du cycle de mise à jour des navigateurs. Il est donc essentiel de s’assurer que la configuration HTTPS est stable et que tous les sous-domaines sont correctement gérés avant de soumettre l’inscription.

Impact sur la performance SEO

Le HSTS améliore la performance du site de manière mesurable. L’élimination de la redirection 301 HTTP → HTTPS supprime un aller-retour réseau complet, ce qui réduit le TTFB de 50 à 200 millisecondes selon la latence réseau. Cette amélioration se répercute directement sur le LCP qui est une métrique clé des Core Web Vitals et un signal de classement Google.

Avec le HSTS Preload, l’amélioration est encore plus significative car même la première visite bénéficie de la connexion HTTPS directe. Sur les sites à fort trafic de nouveaux visiteurs (campagnes SEA, landing pages de contenu viral), le gain cumulé est substantiel.

Le HSTS contribue également à la consolidation des signaux SEO en garantissant qu’aucune version HTTP du site n’est accessible. Cela élimine le risque de duplicate content entre les versions HTTP et HTTPS et assure que les backlinks pointant vers des URLs HTTP sont automatiquement servis en HTTPS par le navigateur.

Impact sur la sécurité

Le HSTS protège contre plusieurs types d’attaques. L’attaque SSL stripping consiste pour un attaquant positionné entre l’utilisateur et le serveur (réseau Wi-Fi public, point d’accès compromis) à intercepter la requête HTTP initiale et à empêcher la redirection vers HTTPS, maintenant l’utilisateur sur une connexion non chiffrée sans qu’il s’en aperçoive. Le HSTS rend cette attaque impossible car le navigateur refuse d’établir une connexion HTTP.

Le HSTS protège également contre les erreurs de configuration côté serveur qui pourraient accidentellement servir des pages en HTTP, contre les liens internes en HTTP oubliés lors d’une migration, et contre les mixed content involontaires en forçant toutes les requêtes du domaine en HTTPS.

Configuration serveur

Apache nécessite l’ajout de l’en-tête dans le fichier .htaccess ou la configuration du virtual host HTTPS :

apache

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Nginx nécessite l’ajout de l’en-tête dans le bloc server de la configuration HTTPS :

nginx

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

L’en-tête HSTS ne doit être servi que sur les réponses HTTPS. Le servir sur des réponses HTTP est inutile car les navigateurs l’ignorent lorsqu’il est reçu sur une connexion non sécurisée, et la spécification l’interdit explicitement pour éviter les injections malveillantes.

Erreurs fréquentes

• Activer includeSubDomains alors que certains sous-domaines ne sont pas configurés en HTTPS rend ces sous-domaines inaccessibles, car le navigateur refusera toute connexion HTTP vers eux.
• Commencer avec un max-age très long (un an) sans phase de test empêche de revenir en arrière rapidement en cas de problème de configuration HTTPS.
• La bonne pratique est de démarrer avec un max-age court (300 secondes), vérifier que tout fonctionne, puis augmenter progressivement jusqu’à la valeur finale.
• Soumettre le domaine à la liste HSTS Preload sans avoir vérifié tous les sous-domaines peut rendre des services internes ou des sous-domaines de développement inaccessibles.
• Servir l’en-tête HSTS uniquement sur la page d’accueil et pas sur toutes les réponses du serveur laisse des pages non protégées si l’utilisateur y accède directement.
• Oublier de renouveler le certificat SSL/TLS sur un site avec HSTS actif rend le site complètement inaccessible, car le navigateur refuse la connexion HTTP de fallback et la connexion HTTPS échoue à cause du certificat expiré.

Outils de diagnostic

• Chrome DevTools → onglet Security → Vérifie la présence de l’en-tête HSTS dans la réponse du serveur et affiche la politique de sécurité de transport appliquée au domaine
• Chrome → chrome://net-internals/#hsts → Interface interne de Chrome permettant de vérifier si un domaine est dans le cache HSTS du navigateur, de le supprimer manuellement pour les tests, et de vérifier la présence dans la liste Preload
• SSL Labs (ssllabs.com) → Audit complet de la configuration TLS qui vérifie la présence et la validité de l’en-tête HSTS, la valeur du max-age et la présence du paramètre preload
• hstspreload.org → Site officiel pour vérifier l’éligibilité d’un domaine à la liste HSTS Preload, soumettre l’inscription ou demander la suppression
• SecurityHeaders.com → Analyse rapide de tous les en-têtes de sécurité HTTP du site, incluant HSTS, avec scoring et recommandations
• Hardenize → Monitoring continu de la configuration HSTS, des certificats et de l’ensemble des en-têtes de sécurité avec alertes en cas de dégradation
• curl en ligne de commande → Vérification rapide de la présence de l’en-tête via curl -I https://mondomaine.fr pour inspecter les headers de réponse

Besoin d’un accompagnement ?

Configurer le HSTS correctement, du déploiement progressif du max-age à l’inscription sur la liste Preload en passant par la vérification de tous les sous-domaines, c’est sécuriser votre site tout en améliorant vos Core Web Vitals. Notre agence spécialisée en SEO audite votre configuration de sécurité et déploie le HSTS pour optimiser à la fois la protection de vos utilisateurs et la performance de votre site.

→ Contactez notre agence spécialisée en SEO à Lyon

Entités liées (→ définitions dédiées)

→ HTTPS · Certificat SSL/TLS · Redirection 301 · TTFB · LCP · Core Web Vitals · Duplicate Content · Mixed Content · Rendering · Crawl