---\ntitle: HTTP Strict Transport Security (HSTS)\ncheck: missing-strict-transport-security\nnavHidden: true\ncategory: Sécurité\ncreated: 2026-07-16T02:59:36Z\nupdated: 2026-08-23T19:10:16Z\n---\n\n# HTTP Strict Transport Security (HSTS)\n\nSilktide vérifie que vos pages chiffrées indiquent aux navigateurs d’utiliser en tout temps la version sécurisée de votre site Web. Cette instruction, appelée HTTP Strict Transport Security (HSTS), empêche les navigateurs d’établir une connexion non chiffrée, même lorsqu’un visiteur saisit une adresse simple ou suit un ancien lien.\n\nL’instruction est un envoyé avec chaque page via :\n\ntext\nStrict-Transport-Security: max-age=31536000\n\n\n## Pourquoi c’est important\n\nMême un site entièrement servi via HTTPS accepte habituellement d’abord une requête non chiffrée : le visiteur tape example.com, le navigateur essaie http:\/\/, et le serveur redirige vers https:\/\/. Ce seul saut non chiffré suffit à un attaquant sur le même réseau pour intercepter la connexion et maintenir le visiteur sur une version falsifiée ou altérée du site - une attaque de l’homme du milieu (MITM).\n\nHSTS comble cette faille. Une fois que le navigateur a vu l’en-tête, il met à niveau toutes les requêtes futures vers HTTPS de lui-même, aussi longtemps que le max-age l’indique, de sorte que la première requête vulnérable ne se reproduit plus.\n\n## Comment corriger\n\n1. Assurez-vous d’abord que l’ensemble de votre site fonctionne via HTTPS - une fois HSTS actif, les navigateurs refuseront totalement la version non chiffrée.\n2. Configurez votre serveur Web, votre plateforme d’hébergement ou votre pour envoyer l’en-tête Strict-Transport-Security sur toutes les réponses HTTPS. De nombreuses plateformes offrent un paramètre HSTS en un clic.\n3. Définissez une valeur max-age significative en secondes. Commencez petit (par exemple 86400, une journée) si vous souhaitez une période d’essai, puis augmentez à un an (max-age=31536000) lorsque vous êtes confiants.\n4. Facultativement, ajoutez includeSubDomains pour couvrir tous les sous-domaines, mais seulement si tous prennent en charge HTTPS.\n\n## Comment Silktide teste cela\n\n1. Vérifier que chaque page servie via HTTPS contient un en-tête Strict-Transport-Security avec une valeur non vide.\n2. Signaler la page si l’en-tête est absent.\n3. Les pages servies sur des connexions non chiffrées sont ignorées, car les navigateurs y ignorent cet en-tête - la sécurisation de ces pages est couverte par la vérification Chiffrement SSL.\n\n## Dépannage\n\n### J’ai défini l’en-tête, mais la vérification échoue toujours\n\nVérifiez que l’en-tête est envoyé par les pages exactes analysées, et pas seulement par la page d’accueil. Vous pouvez voir les en-têtes de réponse d’une page dans les outils de développement de votre navigateur, sous l’onglet Réseau.\n\n### HSTS peut-il bloquer l’accès des visiteurs ?\n\nSi vous activez HSTS et que vous brisez ensuite votre configuration HTTPS (par exemple, un certificat expiré), les navigateurs qui se souviennent de l’en-tête refuseront de revenir au site non chiffré jusqu’à l’expiration de max-age. C’est intentionnel - automatisez le renouvellement de vos certificats.\n\n## Pour en savoir plus\n\n- En-tête Strict-Transport-Security (MDN)\n- Chiffrement SSL\n- Politique de sécurité du contenu\n