Defaults.Exposed › Corrections › HSTS (Strict-Transport-Security)

Comment corriger HSTS (Strict-Transport-Security)

Le HSTS est une instruction d'une ligne que votre site web donne à chaque navigateur : « reviens toujours vers moi par la connexion sécurisée et chiffrée — jamais par la non sécurisée. » Sans lui, votre cadenas peut être discrètement arraché sur un Wi-Fi partagé, et la toute première visite de votre site est exposée.

En clair, pour votre entreprise : Avoir le HTTPS (le cadenas) n'est pas la même chose que l'imposer. Sans HSTS, un attaquant sur le même Wi-Fi que votre client peut discrètement rétrograder la connexion vers du HTTP ordinaire non chiffré — capturant identifiants, coordonnées bancaires et données de formulaire pendant que le client ne voit rien d'anormal. Votre certificat SSL, que vous payez peut-être, est contourné. La correction est gratuite et prend environ 15 minutes à la personne qui gère votre site.

Ce que cela peut vous coûter

• Les clients sur le Wi-Fi d'un café, d'un hôtel, d'un aéroport ou d'une conférence peuvent voir leur connexion à votre site discrètement rétrogradée et leurs données lues — sans aucun avertissement à l'écran.
• Vous avez payé pour le HTTPS et vous avez le cadenas, mais sans HSTS les attaquants peuvent tout simplement le contourner ; le certificat donne un faux sentiment de sécurité.
• La toute première visite de votre site (avant toute redirection vers HTTPS) est le point faible que visent les attaquants — le HSTS est ce qui le ferme pour chaque visite ultérieure.
• Un questionnaire de sécurité, un formulaire de cyber-assurance ou la liste de contrôle d'un acheteur d'entreprise signale « pas de HSTS » et fait caler l'affaire jusqu'à correction.
• Réglez la valeur de travers (trop courte) et vous obtenez le pire des deux mondes : cela a l'air configuré mais n'offre presque aucune protection réelle.

Pourquoi c'est important. Le HTTPS protège une connexion une fois qu'elle est chiffrée — mais il ne force pas les navigateurs à l'utiliser. Les attaquants exploitent cette brèche avec le « SSL stripping » : sur tout réseau partagé, ils maintiennent discrètement le visiteur en HTTP non sécurisé, lisant tout. Le HSTS dit au navigateur de refuser entièrement le HTTP ordinaire pour votre domaine, pendant longtemps, de sorte que la brèche se ferme après la première visite. C'est un simple en-tête de réponse, gratuit à ajouter, et dans notre notation il vaut de vrais points, car une valeur absente ou trop courte laisse chaque visiteur sur Wi-Fi public exposé.

Ce que c’est, en clair

Vous avez presque certainement le HTTPS — le petit cadenas dans la barre du navigateur. Bien. Mais voici la partie qu’on ne dit presque à personne : avoir le HTTPS n’est pas la même chose que le forcer.

Le HTTPS rend une connexion chiffrée une fois que le navigateur décide de l’utiliser. Le HSTS — abréviation de HTTP Strict Transport Security — est l’instruction qui fait que le navigateur l’utilise toujours. C’est une ligne unique et invisible que votre site web envoie à chaque visiteur et qui dit, en substance :

« À partir de maintenant, pour mon domaine, ne me parle jamais que par la connexion sécurisée. Jamais la non sécurisée. N’essaie même pas. »

Le navigateur s’en souvient et y obéit aussi longtemps que vous le lui indiquez — généralement un an. Après la première visite sécurisée d’un visiteur, son navigateur refusera tout simplement de charger votre site en HTTP ordinaire non chiffré, même si quelque chose tente de le forcer.

Sans HSTS, cette règle du « toujours utiliser la version sécurisée » n’existe pas — et les attaquants savent exactement comment exploiter la brèche.

Ce que cela peut vous coûter

Ce sont des scénarios réalistes et quotidiens. Nous ne nommons jamais d’entreprise réelle ; ce sont des illustrations de la façon dont la brèche est exploitée.

1. La commande au café. Un client ouvre votre boutique sur le Wi-Fi d’un café et passe à la commande. Un attaquant sur le même réseau exécute un outil gratuit et bien connu qui maintient le client en HTTP ordinaire au lieu du HTTPS. Le client voit ce qui ressemble à votre site normal — pas d’avertissement, pas de cadenas brisé à l’endroit où il jetterait un œil — et saisit ses coordonnées bancaires. L’attaquant lit chaque frappe. Votre certificat SSL n’a servi à rien, car la connexion n’a jamais été autorisée à devenir sécurisée en premier lieu.

2. L’employé en déplacement. Un collaborateur se connecte à votre panneau d’administration ou à votre webmail depuis un hôtel ou un aéroport. La même astuce de rétrogradation capture son nom d’utilisateur et son mot de passe. L’attaquant a désormais une voie d’accès à votre entreprise — non parce que votre politique de mot de passe était faible, mais parce que la page de connexion était accessible en HTTP non sécurisé.

3. L’affaire qui cale. Un client plus important vous envoie son questionnaire de sécurité standard avant de signer. Une ligne demande : « Votre site web impose-t-il le HTTPS via HSTS ? » Votre contact informatique doit répondre « non », et le processus d’achat s’interrompt pendant que vous vous démenez pour corriger un réglage gratuit de 15 minutes qui ressemble désormais à un signal rouge devant un acheteur.

4. Le contrôle de cyber-assurance ou de conformité. Le scan d’un assureur, ou un auditeur examinant votre posture de protection des données, signale l’en-tête manquant. Le chiffrement des données personnelles est une attente explicite des règles de protection des données (article 32 du RGPD), et « nous avons un certificat mais ne l’imposons pas » est une position fragile.

5. Le faux sentiment de sécurité. Vous payez pour le SSL, le cadenas s’affiche, et tout le monde suppose que le site est sûr. Il l’est essentiellement — jusqu’à ce qu’un client soit sur un réseau partagé, ce qui est exactement le moment où il est le plus vulnérable et le moins susceptible de remarquer quoi que ce soit d’anormal.

Le fil rouge : le coût n’est pas abstrait. C’est la carte ou l’identifiant d’un vrai client, capturé au pire moment possible, sans qu’aucune alarme ne se déclenche.

Ce que c’est réellement

Quand un navigateur demande une page à votre site web, votre serveur renvoie la page plus quelques « en-têtes » invisibles — des instructions supplémentaires que le navigateur lit mais que le visiteur ne voit jamais. Le HSTS est l’un de ces en-têtes :

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

Trois éléments comptent :

• max-age — combien de temps (en secondes) le navigateur doit se souvenir de forcer le HTTPS. 31536000 correspond à un an. C’est le cœur du sujet : trop court et cela n’aide quasiment pas.
• includeSubDomains — étend la règle à chaque sous-domaine (boutique., app., mail., etc.), pas seulement à votre adresse principale.
• preload — inscrit votre domaine dans une liste maîtresse intégrée aux navigateurs, pour que la protection s’applique même lors de la toute première requête d’un visiteur, avant qu’il ait jamais vu votre site.

Pourquoi « la première visite » compte

Le HSTS a une limite inhérente : un navigateur n’obéit à la règle qu’après avoir vu l’en-tête au moins une fois. La toute première connexion d’un visiteur tout neuf reste donc une minuscule fenêtre d’exposition. Deux choses la réduisent : une redirection HTTP vers HTTPS (qui l’amène vite vers la version sécurisée) et le preload (qui supprime entièrement la fenêtre). C’est pourquoi une configuration complète associe le HSTS à une redirection correcte.

À quoi ressemble le « bon » réglage — et comment il se note

Notre contrôle lit votre en-tête en direct et note le max-age :

Ainsi, un en-tête qui existe mais est réglé sur quelques minutes est traité comme un échec — il a l’air configuré mais ne fait pas le travail. Visez un an. Le contrôle note aussi si includeSubDomains et preload sont présents.

Comment corriger (gratuit, ~15 minutes)

Transmettez cette section à la personne qui gère votre site web — votre informaticien, votre développeur web, ou le support de votre hébergeur. La correction est gratuite. C’est un en-tête unique, ou un bouton dans votre plateforme d’hébergement. Il n’y a rien à acheter.

Une règle d’ordre importante d’abord : le HSTS est tenace — une fois activé, les navigateurs refuseront le HTTP ordinaire pour votre domaine pendant tout le max-age. Confirmez donc que le HTTPS fonctionne correctement sur votre site principal et chaque sous-domaine avant de l’activer largement. La voie sûre est : tester avec une courte valeur → confirmer que rien ne casse → monter à un an.

Étape 1 — Vérifiez que le HTTPS fonctionne déjà partout

Visitez votre site et vos sous-domaines clés en https:// et confirmez qu’ils se chargent proprement avec un certificat valide. Confirmez aussi que les requêtes http:// ordinaires redirigent vers https://. (Si ce n’est pas le cas, corrigez d’abord la redirection HTTP vers HTTPS — le HSTS suppose qu’elle est en place.)

Étape 2 — Ajoutez l’en-tête (choisissez votre plateforme)

Cloudflare (ou CDN similaire) : C’est le plus facile. Allez dans SSL/TLS → Edge Certificates → HTTP Strict Transport Security (HSTS) et activez-le. Réglez Max-Age sur 6 mois ou 12 mois, et activez « Apply HSTS policy to subdomains » une fois certain que tous les sous-domaines sont en HTTPS.

Nginx : ajoutez à l’intérieur de votre bloc server HTTPS :

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

Apache : assurez-vous que mod_headers est activé, puis ajoutez à votre hôte virtuel HTTPS :

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

Microsoft IIS : ajoutez à web.config à l’intérieur de <customHeaders> :

<add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains; preload" />

Note Google Workspace / Microsoft 365 : ceux-ci alimentent votre messagerie, pas l’hébergement de votre site web — le HSTS se définit là où vit réellement votre site web public (votre CDN, votre serveur web ou votre créateur de site), et non dans l’administration Workspace/365. Si votre site est sur un créateur comme Squarespace, Wix ou Shopify, le HSTS est généralement géré pour vous ; vérifiez leurs réglages SSL/sécurité si notre contrôle le signale.

Étape 3 — Testez petit, puis engagez-vous

Commencez avec max-age=300 (5 minutes). Confirmez que le site se charge encore parfaitement partout. Puis montez à max-age=31536000 (un an). C’est le réglage qui rapporte la note maximale.

Étape 4 (optionnel, référence absolue) — preload

Une fois confiant et après avoir fait tourner un moment un en-tête d’un an avec includeSubDomains, vous pouvez soumettre votre domaine sur hstspreload.org pour qu’il soit intégré aux navigateurs. Cela ferme entièrement la fenêtre de la première visite. Considérez-le comme un engagement délibéré — retirer un domaine de la liste est lent.

Erreurs fréquentes

• Régler le max-age trop court. Une valeur de quelques minutes ou heures a l’air configurée mais n’offre presque aucune protection — et notre contrôle traite tout ce qui est en dessous d’un jour comme un échec. Mettez un an.
• Activer includeSubDomains avant que les sous-domaines soient prêts pour le HTTPS. Si un sous-domaine n’est pas entièrement en HTTPS, la règle tenace peut le rendre inaccessible aux visiteurs. Mettez d’abord chaque sous-domaine en HTTPS.
• Ajouter le HSTS sans avoir de redirection HTTP vers HTTPS. Le HSTS suppose que les visiteurs atteignent la version sécurisée ; sans la redirection, la première visite est inutilement exposée. Corrigez les deux ensemble.
• Foncer directement vers preload pour « être minutieux ». Le preload est difficile à annuler. Méritez-le progressivement après un en-tête d’un an stable — ne le précipitez pas.
• Croire que le cadenas signifie que vous êtes couvert. Le cadenas et le HSTS sont deux choses différentes. Vous pouvez avoir un certificat parfait et échouer quand même à ce contrôle.

FAQ