HSTS : le header qui empêche le retour au HTTP

HSTS est un en-tête HTTP qui dit au navigateur : « à partir de maintenant, ne parle plus jamais à ce site en HTTP, uniquement en HTTPS ». Une ligne de configuration, un gain de sécurité disproportionné. Mais activé sans précaution, HSTS peut rendre un site inaccessible pendant des semaines. Voici ce qu'on regarde en audit, ce qu'on active en durcissement, et les pièges qu'on évite chez nos clients.

Définition en une phrase

HSTS (HTTP Strict Transport Security) est un en-tête de réponse HTTP qui ordonne au navigateur de forcer toutes les futures connexions vers votre domaine en HTTPS, y compris si l'utilisateur tape l'URL en http://.

En clair, pour les non-initiés. Sans HSTS, un visiteur qui tape mon-site.fr sans préciser https:// peut être intercepté sur la toute première requête par un attaquant sur le même réseau Wi-Fi. HSTS supprime cette fenêtre d'interception : le navigateur corrige en HTTPS avant d'envoyer la requête.

Pourquoi c'est important pour votre site

En 2026, 100 % des sites sérieux sont en HTTPS. Le rôle de HSTS n'est plus « chiffrer » (le certificat TLS le fait déjà) mais empêcher le retour en HTTP. Trois scénarios concrets où HSTS nous sauve :

• Wi-Fi public compromis. Un client qui se connecte depuis un hôtel ou un café : sans HSTS, la première requête HTTP peut être détournée vers un faux site.
• Redirection http:// vers https:// qui échoue. Un plugin de cache, une règle Cloudflare mal configurée, et la redirection saute. Sans HSTS, le navigateur accepte le HTTP et expose le trafic. Avec HSTS actif, il refuse catégoriquement.
• Cookies volés. Un cookie de session marqué Secure n'est jamais envoyé en HTTP. Mais si le navigateur visite d'abord une ressource sous-domaine en HTTP, des fuites sont possibles. HSTS includeSubDomains verrouille tout.

Sur nos audits P.01, HSTS manque dans environ 70 % des sites WordPress et PrestaShop que nous regardons. C'est le header le plus souvent oublié de notre checklist.

Comment ça fonctionne, concrètement

HSTS est un en-tête de réponse HTTP avec trois paramètres :

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

• max-age : durée en secondes pendant laquelle le navigateur doit forcer HTTPS. 31536000 = 1 an. C'est la valeur standard.
• includeSubDomains : applique la règle à tous les sous-domaines (api.mon-site.fr, blog.mon-site.fr, etc.). Puissant mais à manier avec prudence, voir la section pièges plus bas.
• preload : demande à être ajouté à la liste preload intégrée dans Chrome, Firefox, Safari, Edge. Le navigateur force HTTPS avant même la première visite. Quasiment irréversible.

Le navigateur mémorise la directive côté client. Tant que max-age n'est pas expiré ou explicitement remis à 0, il refusera toute connexion HTTP au domaine.

Pour qu'un navigateur prenne HSTS en compte, la première requête doit arriver en HTTPS. Un client qui accède à votre site en HTTP pour la toute première fois et ne voit jamais de réponse HTTPS ne sera jamais « instruit ». C'est pourquoi HSTS est toujours associé à une redirection 301 http:// vers https:// côté serveur ou Cloudflare.

Comment Secushot configure HSTS en intervention

Dans notre protocole P.03 Durcissement et notre pack PK.CFE Sérénité Cloudflare, voici la séquence standard :

1. On vérifie que le site est 100 % HTTPS sur tous les sous-domaines qu'on connaît. Un seul sous-domaine en HTTP casse un HSTS includeSubDomains.
2. On active HSTS avec un max-age court (300 secondes, soit 5 minutes) pendant 48 h en observation. Ça permet de revenir en arrière si un sous-domaine oublié casse.
3. On monte progressivement : 1 jour, puis 7 jours, puis 6 mois, puis 1 an.
4. includeSubDomains n'est ajouté que si on a la cartographie complète des sous-domaines du client.
5. preload n'est quasiment jamais activé par défaut. On en parle plus bas.

Côté serveur, on l'ajoute selon la stack :

• Cloudflare : onglet SSL/TLS → Edge Certificates → Enable HSTS (interface avec garde-fous).
• Apache : dans le vhost HTTPS, Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains".
• Nginx : add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;.
• WordPress via plugin sécurité : déconseillé. Un plugin qui pilote des headers HTTP est une dépendance qui peut sauter après mise à jour. On préfère la config serveur ou Cloudflare.

Le header est vérifié dans tous nos audits préventifs (P.01), avec un signalement en sévérité haute s'il est absent sur un site en production.

Les erreurs qu'on rencontre le plus souvent

1. preload activé sans s'en rendre compte

Ajouter le domaine à la liste preload Chromium est quasi irréversible. Retirer un domaine prend plusieurs semaines, plus le temps de propagation des nouvelles versions de navigateurs (6 à 12 mois au total). Nous avons vu des agences activer preload sur un domaine client, puis devoir gérer pendant 6 mois un sous-domaine legacy en HTTP devenu inaccessible. Notre règle : on ne preload que les domaines dont on maîtrise l'ensemble de la stack sur 5 ans.

2. includeSubDomains sur un domaine avec des sous-domaines oubliés

Classique en e-commerce : le domaine principal est en HTTPS, mais old-shop.mon-site.fr (une ancienne boutique PrestaShop) est resté en HTTP. Activer includeSubDomains coupe l'accès au legacy. On cartographie systématiquement les enregistrements DNS avant d'activer.

3. HSTS activé sans redirection 301 HTTP vers HTTPS

Le header n'est envoyé que sur les réponses HTTPS. Si un visiteur tape http://mon-site.fr et que le serveur répond en HTTP 200 (sans redirection), HSTS n'est jamais appliqué. Il faut la paire : redirection 301 côté serveur ou CDN, plus HSTS sur les réponses HTTPS.

4. max-age trop court laissé en production

On voit régulièrement des max-age=3600 (1 heure) oubliés après une phase de test. Un visiteur qui n'est pas revenu depuis plus d'une heure perd la protection. On vérifie et on remonte à au moins 6 mois en durcissement.

Questions fréquentes

HSTS remplace-t-il le certificat TLS ? Non. HSTS force l'utilisation de HTTPS. Le chiffrement réel est assuré par le certificat TLS et la négociation TLS 1.2/1.3 (voir notre page TLS 1.2 / 1.3). HSTS sans TLS ne sert à rien.

Faut-il activer HSTS sur un site WordPress ? Oui, dans la majorité des cas. On le fait systématiquement en P.03. Sur un WordPress multisite avec des sous-domaines dont certains pourraient encore être en HTTP, on procède par paliers comme décrit plus haut.

HSTS peut-il casser mon site ? Oui, si un sous-domaine ou un service tiers (CDN, API, webmail) est encore accessible en HTTP et devient inaccessible une fois includeSubDomains propagé. Toujours cartographier avant.

Combien de temps met HSTS à prendre effet ? Dès la première visite en HTTPS avec le header, le navigateur applique la règle jusqu'à expiration du max-age. La prise d'effet est instantanée par client, mais votre base d'utilisateurs entière n'est couverte qu'après leur prochaine visite.

Comment désactiver HSTS si on a fait une erreur ? En renvoyant le header Strict-Transport-Security: max-age=0. Le navigateur supprime la règle à la prochaine visite HTTPS. Si preload a été activé et le domaine soumis à la liste Chromium, c'est beaucoup plus long, voir le point 1 des erreurs.

Cloudflare propose un toggle HSTS, je peux me contenter de ça ? Oui dans la majorité des cas, et c'est même ce qu'on fait chez nos clients PK.CFE. L'interface Cloudflare pose les bonnes questions (preload, includeSubDomains) avec des garde-fous. Attention : cela suppose que Cloudflare soit en mode Full (Strict), pas Flexible. Sinon HSTS force HTTPS côté visiteur mais le backend est contacté en HTTP, ce qui crée une faille silencieuse.

Pour aller plus loin

• Connexe : TLS 1.2 / 1.3, CSP (Content Security Policy), Cloudflare WAF.
• Protocole concerné : nous activons HSTS dans le durcissement sécurité P.03 et systématiquement dans le pack Sérénité Cloudflare (PK.CFE). Il est également audité sans activation dans l'audit préventif P.01.

HSTS absent ou mal configuré sur votre site ? Notre audit préventif (P.01, 490 € TTC, livré en 48 h) vérifie HSTS et l'ensemble des headers HTTP de sécurité. Sans aucun accès serveur. Rapport PDF priorisé. Briefer un audit préventif