# Strict-Transport-Security (/fr/docs/web-security/security-headers/strict-transport-security) HTTP Strict Transport Security (HSTS) est un header de réponse qu'un site envoie en HTTPS pour dire au navigateur de n'atteindre cet hôte qu'en HTTPS, pendant une durée que vous choisissez. Une fois que le navigateur a vu le header, il réécrit toute adresse `http://` en clair de l'hôte en `https://` avant même que la requête ne quitte la machine, même si l'utilisateur a tapé l'adresse non sécurisée ou suivi un ancien lien. Sans lui, taper un simple domaine dans la barre d'adresse commence par une requête HTTP en clair, et quiconque se trouve sur le chemin réseau (un point d'accès Wi-Fi public, un routeur compromis) peut lire ou réécrire ce saut non chiffré et maintenir la victime sur une version HTTP du site contrôlée par l'attaquant. HSTS supprime cette ouverture en faisant refuser au navigateur de parler HTTP en clair à votre hôte, tout simplement. Voici le header tel que vous le déploieriez après un déploiement complet (voir [comment le mettre en place](#comment-le-mettre-en-place) avant de le copier) : ```http Strict-Transport-Security: max-age=63072000; includeSubDomains; preload ``` ## Valeurs et ce que fait chacune [#valeurs-et-ce-que-fait-chacune] | Directive | Statut | Description | | ------------------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `max-age=` | ✅ Bon | Obligatoire. Durée pendant laquelle le navigateur impose HTTPS pour l'hôte. Le minuteur se réinitialise à chaque réponse, donc une valeur fixe n'expire pratiquement jamais pour les visiteurs qui reviennent. | | `includeSubDomains` | ✅ Bon | Étend la politique de l'hôte à tous ses sous-domaines, vers le bas uniquement. | | `preload` | ✅ Bon | Inscrit le domaine dans la liste de preload des navigateurs sur [hstspreload.org](https://hstspreload.org/). Non standard (absent du RFC 6797) et difficile à défaire ; ne soumettez que lorsque tout le domaine est prêt. | | `max-age=0` | ❌ Risqué | L'interrupteur d'arrêt. Dit au navigateur d'oublier la politique, y compris `includeSubDomains`. Ne l'utilisez que pour revenir en arrière, et notez qu'il ne prend effet qu'à la prochaine réponse reçue en HTTPS valide. | La politique s'attache à l'hôte exact qui a servi le header. Un header sur `www.example.com` ne couvre jamais `example.com`, et il ne couvre les sous-domaines que lorsque `includeSubDomains` est présent, et uniquement vers le bas : une politique sur `secure.example.com` couvre `login.secure.example.com` mais pas `example.com` ni les hôtes voisins. HSTS identifie les hôtes par nom de domaine uniquement, donc il ne s'applique jamais à un hôte adressé par IP. Les navigateurs ignorent entièrement le header quand il arrive en HTTP en clair. ## Contre quoi cela protège [#contre-quoi-cela-protège] * **Le SSL stripping et les attaques de rétrogradation.** Un attaquant actif sur le réseau peut intercepter une requête HTTP en clair et servir une version HTTP du site, tenant discrètement la victime hors de TLS. Avec HSTS, le navigateur passe l'URL en HTTPS avant que la requête ne parte, donc il n'y a aucune requête non sécurisée à intercepter. * **Le vol de cookie sur le premier saut non sécurisé.** Sans le header, la première requête vers un domaine tapé passe en HTTP en clair, et tout cookie dépourvu de l'attribut `Secure` (voir [sécurité des cookies](/fr/docs/web-security/security-headers/cookie-security)) voyage sur ce saut en clair, où un espion passif peut le copier. * **Les erreurs de contenu mixte sur le même hôte.** Les URL pointant vers un hôte HSTS connu sont réécrites, donc une image ou une référence de script `http://` égarée vers votre propre hôte est passée en HTTPS au lieu de se charger sans sécurité. * **L'usurpation de certificat via un clic de contournement.** Pour un hôte HSTS, le navigateur traite toute erreur de certificat comme fatale. Il n'y a pas de bouton « continuer quand même », donc un attaquant ne peut pas compter sur les utilisateurs pour cliquer au travers d'un avertissement lié à un certificat falsifié. ## Risques sans le header [#risques-sans-le-header] Chaque nouvelle visite commence sans sécurité. Quand un utilisateur tape votre domaine ou suit un lien `http://`, le navigateur envoie la première requête en HTTP en clair et attend votre redirection. Ce seul aller-retour non chiffré suffit à un attaquant sur le chemin pour détourner la session : les cookies non `Secure` voyagent en clair, et un attaquant actif peut répondre lui-même à la requête et ne jamais laisser l'utilisateur atteindre HTTPS. Une redirection côté serveur vers HTTPS ne comble pas cette faille, car la redirection n'a lieu qu'après que la requête non sécurisée a déjà été envoyée et peut-être altérée. ## Risques et pièges à l'usage [#risques-et-pièges-à-lusage] * **La première visite n'est pas protégée.** HSTS ne fonctionne qu'une fois que le navigateur a reçu le header au moins une fois en HTTPS valide. La toute première requête d'un nouveau navigateur, et la première requête après l'expiration de la politique, partent encore en HTTP en clair, sauf si le domaine figure sur la liste de preload. * **Le preload est quasi permanent.** OWASP prévient de conséquences permanentes si un site preloadé doit un jour repasser en HTTP. Le retrait de la liste exige d'abord d'enlever la directive `preload`, puis prend 6 à 12 semaines pour atteindre la plupart des utilisateurs de Chrome et plus longtemps pour les autres navigateurs, et les exigences de soumission s'appliquent tant que vous êtes listé. Avec `includeSubDomains`, le preload force aussi chaque sous-domaine vers HTTPS, y compris les hôtes internes en HTTP seul que les navigateurs ne peuvent plus atteindre. Auditez tous les sous-domaines imbriqués avant de soumettre. * **Des non-effets silencieux.** La mauvaise configuration la plus courante est d'envoyer le header sur des réponses HTTP en clair, que les navigateurs doivent ignorer, donc rien ne se passe et rien ne vous avertit. Le header est aussi ignoré sur les réponses présentant des erreurs de certificat. Et comme la politique se lie à l'hôte exact, le servir sur `www.example.com` alors que l'apex `example.com` n'envoie rien laisse l'apex sans protection. ## Comment le mettre en place [#comment-le-mettre-en-place] Augmentez `max-age` par étapes, comme le recommande [hstspreload.org](https://hstspreload.org/), pour qu'une erreur bloque les utilisateurs pendant des minutes, pas des années : 1. Servez tout le site en HTTPS, y compris `www` et chaque sous-domaine que vous comptez couvrir. 2. Configurez l'écouteur HTTP pour répondre à chaque requête par une redirection permanente (301) vers l'URL HTTPS, sans le header HSTS. Le RFC 6797 interdit de l'envoyer sur un transport non sécurisé, et les navigateurs l'ignorent de toute façon là. 3. Ajoutez le header à toutes les réponses HTTPS avec d'abord une petite valeur : `max-age=300; includeSubDomains` (5 minutes). 4. Montez-la à `max-age=604800` (1 semaine), puis `max-age=2592000` (1 mois), en laissant s'écouler le `max-age` complet de chaque étape et en surveillant les casses avant l'étape suivante. 5. Assurez-vous que le domaine apex sert aussi le header, pas seulement `www` ; chaque hôte doit le recevoir directement. 6. Quand rien n'a cassé, passez à `max-age=63072000` (2 ans) et, si vous voulez une protection dès la première visite, ajoutez `preload` et soumettez le domaine sur [hstspreload.org](https://hstspreload.org/). 7. Vérifiez le header déployé, et le reste de vos headers de réponse, avec le [scanner de headers de sécurité](/tools/security-headers). ## Recommandation [#recommandation] Envoyez `Strict-Transport-Security` sur chaque réponse HTTPS, avec un `max-age` de 2 ans, `includeSubDomains` et `preload` une fois le déploiement terminé : ```http Strict-Transport-Security: max-age=63072000; includeSubDomains; preload ``` C'est la valeur que recommande le [cheat sheet OWASP sur HTTP Strict Transport Security](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html) : un `max-age` de 2 ans avec couverture des sous-domaines et preload. Traitez-la comme l'état final, pas le point de départ. Atteignez-la via la montée progressive ci-dessus, et n'ajoutez `preload` qu'une fois que chaque sous-domaine tourne en HTTPS et que vous acceptez que la décision soit quasi permanente. ## Prise en charge par les navigateurs [#prise-en-charge-par-les-navigateurs] Baseline largement disponible : Chrome, Firefox et Safari imposent tous le header, donc la prise en charge est de fait universelle. La directive `preload` ne fait pas partie du RFC 6797, mais la liste de preload qu'elle alimente est consommée par tous les grands navigateurs. ## FAQ [#faq] ### HSTS protège-t-il la première visite ? [#hsts-protège-t-il-la-première-visite-] Non. HSTS ne prend effet qu'une fois que le navigateur a reçu le header au moins une fois en HTTPS valide, si bien que la toute première requête d'un nouveau navigateur, et la première après l'expiration de la politique, partent encore en HTTP en clair. Le preload comble cet écart en embarquant la politique dans le navigateur. ### Quel est un bon max-age pour HSTS ? [#quel-est-un-bon-max-age-pour-hsts-] Deux ans (`max-age=63072000`) avec `includeSubDomains` et `preload`, la valeur que recommande la cheat sheet OWASP. Ne commencez pas là. Montez depuis une petite valeur comme `max-age=300`, en laissant s'écouler chaque étape et en surveillant les casses, puis passez à l'état final de deux ans une fois que chaque sous-domaine tourne en HTTPS. ### Comment désactiver HSTS ? [#comment-désactiver-hsts-] Envoyez `max-age=0` en HTTPS. Le navigateur cesse de traiter l'hôte comme un hôte HSTS connu à la prochaine réponse qu'il reçoit en HTTPS valide, ce qui efface aussi `includeSubDomains`. Si le domaine est preloadé, enlevez d'abord la directive `preload` et utilisez le formulaire de retrait, qui met des semaines à se propager. ### HSTS couvre-t-il les sous-domaines ? [#hsts-couvre-t-il-les-sous-domaines-] Seulement lorsque `includeSubDomains` est présent, et uniquement vers le bas. La politique s'attache à l'hôte exact qui a servi le header, donc un header sur `secure.example.com` couvre `login.secure.example.com` mais pas `example.com` ni les hôtes voisins. Sans `includeSubDomains`, il ne couvre que cet hôte, donc l'apex doit envoyer son propre header. ## Voir aussi [#voir-aussi] * [Vue d'ensemble des headers de sécurité](/fr/docs/web-security/security-headers) * [CSP upgrade-insecure-requests](/fr/docs/web-security/policies/content-security-policy/directives/upgrade-insecure-requests), qui passe en HTTPS les sous-ressources non sécurisées dans vos pages ; il complète HSTS plutôt qu'il ne le remplace * [Sécurité des cookies](/fr/docs/web-security/security-headers/cookie-security) pour l'attribut `Secure` que HSTS ne remplace pas * [Headers dépréciés](/fr/docs/web-security/security-headers/deprecated-headers), les headers de l'ère TLS (HPKP, Expect-CT) qui n'ont pas survécu * [Scanner de headers de sécurité](/tools/security-headers) pour vérifier vos headers déployés ## Sources [#sources] * [RFC 6797, HTTP Strict Transport Security](https://datatracker.ietf.org/doc/html/rfc6797) * [MDN, Strict-Transport-Security](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Strict-Transport-Security) * [OWASP, cheat sheet HTTP Strict Transport Security](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html) * [hstspreload.org, la liste de preload HSTS](https://hstspreload.org/)