Dans cet article, nous allons explorer ce qu’est l’erreur \u00ab HSTS missing from HTTP server \u00bb et pourquoi elle est si pr\u00e9occupante pour tout site web qui utilise des redirections HTTPS. Nous vous montrerons ensuite comment corriger ce probl\u00e8me et d\u00e9jouer les pirates, en cinq \u00e9tapes faciles.<\/p>\n
Consultez notre guide vid\u00e9o<\/a> pour corriger l’erreur \u00ab HSTS Missing From HTTP Server \u00bb<\/h3>\n<\/kinsta-video>\nUne introduction \u00e0 l’erreur \u00ab HSTS Missing From HTTP Server \u00bb<\/h2>\n
Pour assurer la s\u00e9curit\u00e9 des visiteurs, il n’est pas rare que les sites effectuent une redirection HTTPS<\/a>. Cette redirection fait passer les visiteurs d’une version HTTP \u00e0 une version HTTPS du site web.<\/p>\nUn utilisateur peut explicitement saisir HTTP dans la barre d’adresse de son navigateur, ou suivre un lien qui pointe vers une version HTTP du site. Dans ces sc\u00e9narios, une redirection peut emp\u00eacher des tiers malveillants de voler les donn\u00e9es du visiteur.<\/p>\n
Cependant, aucune technologie n’est parfaite. Si votre site utilise des redirections HTTPS, vous pouvez \u00eatre sensible \u00e0 une attaque de type Man-In-The-Middle (MITM) connue sous le nom de Secure Sockets Layer (SSL) Stripping<\/a>. Dans le cadre de cette attaque, le pirate bloque la demande de redirection et emp\u00eache le navigateur de charger votre site via le protocole HTTPS. En cons\u00e9quence, le visiteur acc\u00e9dera \u00e0 votre site web via HTTP, ce qui facilite grandement le vol de donn\u00e9es par les pirates.<\/p>\nAlternativement, le pirate peut intercepter la redirection et rediriger les visiteurs vers une version clon\u00e9e de votre site. \u00c0 ce stade, le pirate peut voler toutes les donn\u00e9es que l’utilisateur partage, y compris les mots de passe et les informations de paiement. Certains pirates peuvent \u00e9galement essayer d’inciter les visiteurs \u00e0 t\u00e9l\u00e9charger des logiciels malveillants.<\/p>\n
Il est \u00e9galement possible pour les pirates de voler un cookie de session via une connexion non s\u00e9curis\u00e9e, dans une attaque connue sous le nom de d\u00e9tournement de cookie. Ces cookies peuvent contenir une multitude d’informations, notamment des noms d’utilisateur, des mots de passe et m\u00eame des d\u00e9tails de cartes bancaires.<\/p>\n
Pour prot\u00e9ger vos visiteurs contre ces attaques, nous vous recommandons d’activer le protocole HTTP Strict Transport Security (HSTS)<\/a>. Ce protocole oblige le navigateur \u00e0 ignorer toute demande directe et \u00e0 charger votre site via HTTPS.<\/p>\n\nLe protocole HSTS (et pourquoi vous pourriez vouloir l’utiliser)<\/h3>\n
HSTS est une directive de serveur et une politique de s\u00e9curit\u00e9 web. Sp\u00e9cifi\u00e9 par l’Internet Engineering Task Force (IETF) dans la RFC 6797<\/a>, HSTS d\u00e9finit des r\u00e8gles sur la mani\u00e8re dont les agents utilisateurs et les navigateurs web doivent g\u00e9rer leurs connexions pour un site fonctionnant en HTTPS.<\/p>\nParfois, une analyse de s\u00e9curit\u00e9 informatique peut signaler que votre site est \u00ab missing HSTS \u00bb ou \u00ab HTTP Strict Transport Security \u00bb. Si vous rencontrez cette erreur, votre site n’utilise pas HSTS, ce qui signifie que vos redirections HTTPS peuvent mettre vos visiteurs en danger.<\/p>\n
Cette vuln\u00e9rabilit\u00e9 est class\u00e9e comme \u00e9tant \u00e0 risque moyen. Cependant, elle est incroyablement courante et repr\u00e9sente un fruit \u00e0 port\u00e9e de main<\/a> pour les attaquants. Si vous rencontrez cette erreur, il est crucial de la corriger.<\/p>\nEn ajoutant Security Headers HSTS \u00e0 votre serveur, vous pouvez forcer votre site \u00e0 se charger sur le protocole HTTPS. Cela peut contribuer \u00e0 prot\u00e9ger votre site<\/a> contre le d\u00e9tournement de cookies et les attaques de protocole. Puisque vous supprimez potentiellement une redirection de la proc\u00e9dure de chargement, votre site peut \u00e9galement se charger plus rapidement<\/a>.<\/p>\nIl est possible que vous n’ayez pas rencontr\u00e9 cette erreur mais que vous soyez toujours pr\u00e9occup\u00e9 par le HSTS. Si vous n’\u00eates pas s\u00fbr que le HSTS soit activ\u00e9, vous pouvez analyser votre site \u00e0 l’aide d’un outil tel que Security Headers<\/a>. Il suffit de saisir l’URL de votre site Web, puis de cliquer sur Scan.<\/strong><\/p>\n![\"Analysez](\"https:\/\/kinsta.com\/wp-content\/uploads\/2021\/12\/security-headers-scan.png\")
Analysez votre site \u00e0 l’aide de Security Headers<\/figcaption><\/figure>\nSecurity Headers v\u00e9rifiera votre site et affichera tous les en-t\u00eates appliqu\u00e9s dans la section Headers<\/strong>. Si Strict-Transport-Security fait une apparition, alors votre site est prot\u00e9g\u00e9. Toutefois, si cet en-t\u00eate n’est pas r\u00e9pertori\u00e9, nous avons du travail \u00e0 faire.<\/p>\nComment corriger l’erreur \u00ab HSTS Missing From HTTP Server \u00bb (en 5 \u00e9tapes)<\/h2>\n
Pour les pirates, la vuln\u00e9rabilit\u00e9 HSTS est l’occasion id\u00e9ale de voler des donn\u00e9es ou d’inciter vos visiteurs \u00e0 effectuer des actions dangereuses. Voici comment activer la politique HSTS et assurer la s\u00e9curit\u00e9 de votre site.<\/p>\n
\u00c9tape 1 : Cr\u00e9ez une sauvegarde manuelle<\/h3>\n
L’activation de la politique HSTS repr\u00e9sente un changement important pour votre site web. Pour cette raison, nous vous recommandons de cr\u00e9er une sauvegarde \u00e0 la demande<\/a> avant de proc\u00e9der. Cela vous donne la possibilit\u00e9 de restaurer votre site dans le cas peu probable o\u00f9 vous rencontreriez des probl\u00e8mes lors de l’activation de HSTS.<\/p>\nChez Kinsta, nous fournissons des sauvegardes automatiques quotidiennes de WordPress. Cependant, il est toujours judicieux de cr\u00e9er une sauvegarde manuelle avant d’effectuer des changements majeurs. Pour cr\u00e9er ce filet de s\u00e9curit\u00e9, connectez-vous \u00e0 votre tableau de bord MyKinsta<\/a> et s\u00e9lectionnez le site web en question. Ensuite, cliquez sur l’onglet Sauvegardes<\/strong>.<\/p>\n![\"Trouvez](\"https:\/\/kinsta.com\/fr\/wp-content\/uploads\/sites\/4\/2022\/01\/mykinsta-backups-tab.png\")
Trouvez l\u2019onglet Sauvegardes dans MyKinsta<\/figcaption><\/figure>\nEnsuite, s\u00e9lectionnez l’onglet Manuelle<\/strong>. Trouvez le bouton Sauvegarder maintenant<\/strong>, et cliquez dessus.<\/p>\n![\"Cliquez](\"https:\/\/kinsta.com\/fr\/wp-content\/uploads\/sites\/4\/2022\/01\/mykinsta-back-up-now-e1642594331682.png\")
Cliquez sur le bouton \u00ab Sauvegarder maintenant \u00bb<\/figcaption><\/figure>\nVous pouvez maintenant ajouter une courte note \u00e0 votre sauvegarde. Cela peut vous aider \u00e0 l’identifier dans votre tableau de bord MyKinsta.<\/p>\n
Enfin, cliquez sur \u00ab Cr\u00e9er une sauvegarde <\/strong>\u00bb. Nous allons maintenant g\u00e9n\u00e9rer votre sauvegarde et l’ajouter \u00e0 votre tableau de bord.<\/p>\n\u00c9tape 2 : Configurez une redirection HTTP vers HTTPS<\/h3>\n
Avant d’activer la politique HSTS, vous devez d\u00e9ployer un certificat SSL<\/a> sur votre site web. Chez Kinsta, nous prot\u00e9geons automatiquement tous les domaines v\u00e9rifi\u00e9s avec notre int\u00e9gration Cloudflare<\/a>. Cela inclut des certificats SSL gratuits avec prise en charge de wildcard<\/a>. \u00c0 moins que vous n’ayez sp\u00e9cifiquement besoin d’un certificat personnalis\u00e9, vous n’aurez pas \u00e0 vous soucier de configurer SSL manuellement.<\/p>\nEnsuite, vous devrez configurer une redirection HTTP vers HTTPS, si ce n’est pas d\u00e9j\u00e0 fait. Pour cr\u00e9er cette redirection, connectez-vous simplement \u00e0 votre tableau de bord MyKinsta et s\u00e9lectionnez votre site web. Ensuite, cliquez sur Outils.<\/strong><\/p>\n![\"Trouvez](\"https:\/\/kinsta.com\/fr\/wp-content\/uploads\/sites\/4\/2022\/01\/mykinsta-tools-bar.png\")
Trouvez et cliquez sur l\u2019onglet \u00ab Outils \u00bb dans MyKinsta<\/figcaption><\/figure>\nDans la section Forcer HTTPS<\/strong>, cliquez sur le bouton Activer<\/strong>. Vous pouvez maintenant choisir d’utiliser votre domaine principal comme destination, ou demander \u00e0 utiliser un domaine alternatif. Apr\u00e8s avoir pris cette d\u00e9cision, s\u00e9lectionnez Forcer HTTPS<\/strong>.<\/p>\nSachez que si vous utilisez des proxys tiers ou si vous configurez des r\u00e8gles HTTPS personnalis\u00e9es, le fait de forcer HTTPS peut entra\u00eener des erreurs ou d’autres comportements \u00e9tranges. Si vous rencontrez des probl\u00e8mes, vous pouvez toujours contacter notre \u00e9quipe de support<\/a>\u00a0qui se fera un plaisir de vous aider.<\/p>\nSi votre serveur web utilise Nginx<\/a>, vous pouvez rediriger tout votre trafic HTTP vers HTTPS. Il suffit d’ajouter le code suivant<\/a> \u00e0 votre fichier de configuration Nginx :<\/p>\nserver {\n\nlisten 80;\n\nserver_name domain.com www.domain.com;\n\nreturn 301 https:\/\/domain.com$request_uri;\n\n}<\/code><\/pre>\nAlternativement, si vous \u00eates un client de Kinsta, alors nous pouvons effectuer ce changement pour vous. Ouvrez simplement un ticket de support<\/a>\u00a0et faites-nous savoir quel domaine doit \u00eatre dirig\u00e9, et nous nous occuperons du reste.<\/p>\n\u00c9tape 3 : Ajoutez l’en-t\u00eate HSTS<\/h3>\n
Il existe diff\u00e9rents types de directives<\/a> et de niveaux de s\u00e9curit\u00e9 que vous pouvez appliquer \u00e0 votre en-t\u00eate HSTS. Toutefois, nous vous recommandons d’ajouter la directive max-age, car elle d\u00e9finit la dur\u00e9e en secondes pendant laquelle le serveur web doit assurer la livraison via HTTPS. Cela bloque l’acc\u00e8s aux pages ou aux sous-domaines qui ne peuvent \u00eatre servis que par HTTP.<\/p>\nSi vous utilisez un serveur Apache<\/a>, vous devez ouvrir votre fichier virtual hosts. Vous pouvez ensuite ajouter ce qui suit :<\/p>\nHeader always set Strict-Transport-Security max-age=31536000<\/code><\/pre>\nChez Kinsta, nous utilisons des serveurs Nginx. Si vous \u00eates un client de Kinsta, vous pouvez ajouter ce qui suit \u00e0 votre fichier de configuration Nginx :<\/p>\n
add_header Strict-Transport-Security \"max-age=31536000; includeSubDomains; preload\";<\/code><\/pre>\nComme toujours, nous pouvons faire tout le travail difficile pour vous. Il vous suffit d’ouvrir un ticket de support pour nous demander d’ajouter un en-t\u00eate HSTS \u00e0 votre site. Notre \u00e9quipe se fera un plaisir d’apporter cette modification \u00e0 votre fichier Nginx.<\/p>\n
\u00c9tape 4 : Soumettez votre site \u00e0 la liste de pr\u00e9chargement HSTS<\/h3>\n
Il y a un inconv\u00e9nient majeur \u00e0 la politique HSTS. Un navigateur doit rencontrer l’en-t\u00eate HSTS au moins une fois avant de pouvoir l’utiliser pour de futures visites. Cela signifie que votre public devra effectuer le processus de redirection de HTTP \u00e0 HTTPS au moins une fois. Pendant ce temps, ils seront vuln\u00e9rables aux attaques bas\u00e9es sur le protocole.<\/p>\n
Pour tenter de combler cette faille de s\u00e9curit\u00e9, Google a cr\u00e9\u00e9 la liste de pr\u00e9chargement HSTS<\/a>. Celle-ci r\u00e9pertorie tous les sites web qui prennent en charge le HSTS, qui est ensuite cod\u00e9 en dur dans Chrome. En ajoutant votre site \u00e0 cette liste, les visiteurs n’auront plus \u00e0 effectuer une redirection HTTPS initiale.<\/p>\nLa plupart des principaux navigateurs Internet ont leurs propres listes de pr\u00e9chargement HSTS, qui sont bas\u00e9es sur la liste de Chrome. Pour figurer sur cette liste, votre site doit r\u00e9pondre aux crit\u00e8res de soumission<\/a>. La bonne nouvelle est que nous avons d\u00e9j\u00e0 couvert toutes ces exigences, vous pouvez donc aller de l’avant et soumettre votre site \u00e0 la liste de pr\u00e9chargement HSTS.<\/p>\nUne fois que vous \u00eates sur cette liste, certains outils d’optimisation des moteurs de recherche (SEO)<\/a> peuvent vous mettre en garde contre les redirections 307<\/a>. Ces redirections se produisent lorsque quelqu’un tente d’acc\u00e9der \u00e0 votre site via un protocole HTTP non s\u00e9curis\u00e9. Cela d\u00e9clenche une redirection 307 au lieu d’une redirection 301 permanente<\/a>. Si cela vous pr\u00e9occupe, vous pouvez utiliser httpstatus<\/a> pour analyser votre site et v\u00e9rifier si une redirection 301 a lieu.<\/p>\n\u00c9tape 5. V\u00e9rifiez votre en-t\u00eate Strict-Transport-Security<\/h3>\n
Apr\u00e8s avoir ajout\u00e9 l’en-t\u00eate HSTS, il est bon de v\u00e9rifier qu’il fonctionne correctement. Vous pouvez effectuer cette v\u00e9rification \u00e0 l’aide des outils web int\u00e9gr\u00e9s de votre navigateur.<\/p>\n
Une introduction \u00e0 l’erreur \u00ab HSTS Missing From HTTP Server \u00bb<\/h2>\n
Pour assurer la s\u00e9curit\u00e9 des visiteurs, il n’est pas rare que les sites effectuent une redirection HTTPS<\/a>. Cette redirection fait passer les visiteurs d’une version HTTP \u00e0 une version HTTPS du site web.<\/p>\n Un utilisateur peut explicitement saisir HTTP dans la barre d’adresse de son navigateur, ou suivre un lien qui pointe vers une version HTTP du site. Dans ces sc\u00e9narios, une redirection peut emp\u00eacher des tiers malveillants de voler les donn\u00e9es du visiteur.<\/p>\n Cependant, aucune technologie n’est parfaite. Si votre site utilise des redirections HTTPS, vous pouvez \u00eatre sensible \u00e0 une attaque de type Man-In-The-Middle (MITM) connue sous le nom de Secure Sockets Layer (SSL) Stripping<\/a>. Dans le cadre de cette attaque, le pirate bloque la demande de redirection et emp\u00eache le navigateur de charger votre site via le protocole HTTPS. En cons\u00e9quence, le visiteur acc\u00e9dera \u00e0 votre site web via HTTP, ce qui facilite grandement le vol de donn\u00e9es par les pirates.<\/p>\n Alternativement, le pirate peut intercepter la redirection et rediriger les visiteurs vers une version clon\u00e9e de votre site. \u00c0 ce stade, le pirate peut voler toutes les donn\u00e9es que l’utilisateur partage, y compris les mots de passe et les informations de paiement. Certains pirates peuvent \u00e9galement essayer d’inciter les visiteurs \u00e0 t\u00e9l\u00e9charger des logiciels malveillants.<\/p>\n Il est \u00e9galement possible pour les pirates de voler un cookie de session via une connexion non s\u00e9curis\u00e9e, dans une attaque connue sous le nom de d\u00e9tournement de cookie. Ces cookies peuvent contenir une multitude d’informations, notamment des noms d’utilisateur, des mots de passe et m\u00eame des d\u00e9tails de cartes bancaires.<\/p>\n Pour prot\u00e9ger vos visiteurs contre ces attaques, nous vous recommandons d’activer le protocole HTTP Strict Transport Security (HSTS)<\/a>. Ce protocole oblige le navigateur \u00e0 ignorer toute demande directe et \u00e0 charger votre site via HTTPS.<\/p>\n\n HSTS est une directive de serveur et une politique de s\u00e9curit\u00e9 web. Sp\u00e9cifi\u00e9 par l’Internet Engineering Task Force (IETF) dans la RFC 6797<\/a>, HSTS d\u00e9finit des r\u00e8gles sur la mani\u00e8re dont les agents utilisateurs et les navigateurs web doivent g\u00e9rer leurs connexions pour un site fonctionnant en HTTPS.<\/p>\n Parfois, une analyse de s\u00e9curit\u00e9 informatique peut signaler que votre site est \u00ab missing HSTS \u00bb ou \u00ab HTTP Strict Transport Security \u00bb. Si vous rencontrez cette erreur, votre site n’utilise pas HSTS, ce qui signifie que vos redirections HTTPS peuvent mettre vos visiteurs en danger.<\/p>\n Cette vuln\u00e9rabilit\u00e9 est class\u00e9e comme \u00e9tant \u00e0 risque moyen. Cependant, elle est incroyablement courante et repr\u00e9sente un fruit \u00e0 port\u00e9e de main<\/a> pour les attaquants. Si vous rencontrez cette erreur, il est crucial de la corriger.<\/p>\n En ajoutant Security Headers HSTS \u00e0 votre serveur, vous pouvez forcer votre site \u00e0 se charger sur le protocole HTTPS. Cela peut contribuer \u00e0 prot\u00e9ger votre site<\/a> contre le d\u00e9tournement de cookies et les attaques de protocole. Puisque vous supprimez potentiellement une redirection de la proc\u00e9dure de chargement, votre site peut \u00e9galement se charger plus rapidement<\/a>.<\/p>\n Il est possible que vous n’ayez pas rencontr\u00e9 cette erreur mais que vous soyez toujours pr\u00e9occup\u00e9 par le HSTS. Si vous n’\u00eates pas s\u00fbr que le HSTS soit activ\u00e9, vous pouvez analyser votre site \u00e0 l’aide d’un outil tel que Security Headers<\/a>. Il suffit de saisir l’URL de votre site Web, puis de cliquer sur Scan.<\/strong><\/p>\n Security Headers v\u00e9rifiera votre site et affichera tous les en-t\u00eates appliqu\u00e9s dans la section Headers<\/strong>. Si Strict-Transport-Security fait une apparition, alors votre site est prot\u00e9g\u00e9. Toutefois, si cet en-t\u00eate n’est pas r\u00e9pertori\u00e9, nous avons du travail \u00e0 faire.<\/p>\n Pour les pirates, la vuln\u00e9rabilit\u00e9 HSTS est l’occasion id\u00e9ale de voler des donn\u00e9es ou d’inciter vos visiteurs \u00e0 effectuer des actions dangereuses. Voici comment activer la politique HSTS et assurer la s\u00e9curit\u00e9 de votre site.<\/p>\n L’activation de la politique HSTS repr\u00e9sente un changement important pour votre site web. Pour cette raison, nous vous recommandons de cr\u00e9er une sauvegarde \u00e0 la demande<\/a> avant de proc\u00e9der. Cela vous donne la possibilit\u00e9 de restaurer votre site dans le cas peu probable o\u00f9 vous rencontreriez des probl\u00e8mes lors de l’activation de HSTS.<\/p>\n Chez Kinsta, nous fournissons des sauvegardes automatiques quotidiennes de WordPress. Cependant, il est toujours judicieux de cr\u00e9er une sauvegarde manuelle avant d’effectuer des changements majeurs. Pour cr\u00e9er ce filet de s\u00e9curit\u00e9, connectez-vous \u00e0 votre tableau de bord MyKinsta<\/a> et s\u00e9lectionnez le site web en question. Ensuite, cliquez sur l’onglet Sauvegardes<\/strong>.<\/p>\n Ensuite, s\u00e9lectionnez l’onglet Manuelle<\/strong>. Trouvez le bouton Sauvegarder maintenant<\/strong>, et cliquez dessus.<\/p>\n Vous pouvez maintenant ajouter une courte note \u00e0 votre sauvegarde. Cela peut vous aider \u00e0 l’identifier dans votre tableau de bord MyKinsta.<\/p>\n Enfin, cliquez sur \u00ab Cr\u00e9er une sauvegarde <\/strong>\u00bb. Nous allons maintenant g\u00e9n\u00e9rer votre sauvegarde et l’ajouter \u00e0 votre tableau de bord.<\/p>\n Avant d’activer la politique HSTS, vous devez d\u00e9ployer un certificat SSL<\/a> sur votre site web. Chez Kinsta, nous prot\u00e9geons automatiquement tous les domaines v\u00e9rifi\u00e9s avec notre int\u00e9gration Cloudflare<\/a>. Cela inclut des certificats SSL gratuits avec prise en charge de wildcard<\/a>. \u00c0 moins que vous n’ayez sp\u00e9cifiquement besoin d’un certificat personnalis\u00e9, vous n’aurez pas \u00e0 vous soucier de configurer SSL manuellement.<\/p>\n Ensuite, vous devrez configurer une redirection HTTP vers HTTPS, si ce n’est pas d\u00e9j\u00e0 fait. Pour cr\u00e9er cette redirection, connectez-vous simplement \u00e0 votre tableau de bord MyKinsta et s\u00e9lectionnez votre site web. Ensuite, cliquez sur Outils.<\/strong><\/p>\n Dans la section Forcer HTTPS<\/strong>, cliquez sur le bouton Activer<\/strong>. Vous pouvez maintenant choisir d’utiliser votre domaine principal comme destination, ou demander \u00e0 utiliser un domaine alternatif. Apr\u00e8s avoir pris cette d\u00e9cision, s\u00e9lectionnez Forcer HTTPS<\/strong>.<\/p>\n Sachez que si vous utilisez des proxys tiers ou si vous configurez des r\u00e8gles HTTPS personnalis\u00e9es, le fait de forcer HTTPS peut entra\u00eener des erreurs ou d’autres comportements \u00e9tranges. Si vous rencontrez des probl\u00e8mes, vous pouvez toujours contacter notre \u00e9quipe de support<\/a>\u00a0qui se fera un plaisir de vous aider.<\/p>\n Si votre serveur web utilise Nginx<\/a>, vous pouvez rediriger tout votre trafic HTTP vers HTTPS. Il suffit d’ajouter le code suivant<\/a> \u00e0 votre fichier de configuration Nginx :<\/p>\n Alternativement, si vous \u00eates un client de Kinsta, alors nous pouvons effectuer ce changement pour vous. Ouvrez simplement un ticket de support<\/a>\u00a0et faites-nous savoir quel domaine doit \u00eatre dirig\u00e9, et nous nous occuperons du reste.<\/p>\n Il existe diff\u00e9rents types de directives<\/a> et de niveaux de s\u00e9curit\u00e9 que vous pouvez appliquer \u00e0 votre en-t\u00eate HSTS. Toutefois, nous vous recommandons d’ajouter la directive max-age, car elle d\u00e9finit la dur\u00e9e en secondes pendant laquelle le serveur web doit assurer la livraison via HTTPS. Cela bloque l’acc\u00e8s aux pages ou aux sous-domaines qui ne peuvent \u00eatre servis que par HTTP.<\/p>\n Si vous utilisez un serveur Apache<\/a>, vous devez ouvrir votre fichier virtual hosts. Vous pouvez ensuite ajouter ce qui suit :<\/p>\n Chez Kinsta, nous utilisons des serveurs Nginx. Si vous \u00eates un client de Kinsta, vous pouvez ajouter ce qui suit \u00e0 votre fichier de configuration Nginx :<\/p>\n Comme toujours, nous pouvons faire tout le travail difficile pour vous. Il vous suffit d’ouvrir un ticket de support pour nous demander d’ajouter un en-t\u00eate HSTS \u00e0 votre site. Notre \u00e9quipe se fera un plaisir d’apporter cette modification \u00e0 votre fichier Nginx.<\/p>\n Il y a un inconv\u00e9nient majeur \u00e0 la politique HSTS. Un navigateur doit rencontrer l’en-t\u00eate HSTS au moins une fois avant de pouvoir l’utiliser pour de futures visites. Cela signifie que votre public devra effectuer le processus de redirection de HTTP \u00e0 HTTPS au moins une fois. Pendant ce temps, ils seront vuln\u00e9rables aux attaques bas\u00e9es sur le protocole.<\/p>\n Pour tenter de combler cette faille de s\u00e9curit\u00e9, Google a cr\u00e9\u00e9 la liste de pr\u00e9chargement HSTS<\/a>. Celle-ci r\u00e9pertorie tous les sites web qui prennent en charge le HSTS, qui est ensuite cod\u00e9 en dur dans Chrome. En ajoutant votre site \u00e0 cette liste, les visiteurs n’auront plus \u00e0 effectuer une redirection HTTPS initiale.<\/p>\n La plupart des principaux navigateurs Internet ont leurs propres listes de pr\u00e9chargement HSTS, qui sont bas\u00e9es sur la liste de Chrome. Pour figurer sur cette liste, votre site doit r\u00e9pondre aux crit\u00e8res de soumission<\/a>. La bonne nouvelle est que nous avons d\u00e9j\u00e0 couvert toutes ces exigences, vous pouvez donc aller de l’avant et soumettre votre site \u00e0 la liste de pr\u00e9chargement HSTS.<\/p>\n Une fois que vous \u00eates sur cette liste, certains outils d’optimisation des moteurs de recherche (SEO)<\/a> peuvent vous mettre en garde contre les redirections 307<\/a>. Ces redirections se produisent lorsque quelqu’un tente d’acc\u00e9der \u00e0 votre site via un protocole HTTP non s\u00e9curis\u00e9. Cela d\u00e9clenche une redirection 307 au lieu d’une redirection 301 permanente<\/a>. Si cela vous pr\u00e9occupe, vous pouvez utiliser httpstatus<\/a> pour analyser votre site et v\u00e9rifier si une redirection 301 a lieu.<\/p>\n Apr\u00e8s avoir ajout\u00e9 l’en-t\u00eate HSTS, il est bon de v\u00e9rifier qu’il fonctionne correctement. Vous pouvez effectuer cette v\u00e9rification \u00e0 l’aide des outils web int\u00e9gr\u00e9s de votre navigateur.<\/p>\nLe protocole HSTS (et pourquoi vous pourriez vouloir l’utiliser)<\/h3>\n
Comment corriger l’erreur \u00ab HSTS Missing From HTTP Server \u00bb (en 5 \u00e9tapes)<\/h2>\n
\u00c9tape 1 : Cr\u00e9ez une sauvegarde manuelle<\/h3>\n
\u00c9tape 2 : Configurez une redirection HTTP vers HTTPS<\/h3>\n
server {\n\nlisten 80;\n\nserver_name domain.com www.domain.com;\n\nreturn 301 https:\/\/domain.com$request_uri;\n\n}<\/code><\/pre>\n\u00c9tape 3 : Ajoutez l’en-t\u00eate HSTS<\/h3>\n
Header always set Strict-Transport-Security max-age=31536000<\/code><\/pre>\nadd_header Strict-Transport-Security \"max-age=31536000; includeSubDomains; preload\";<\/code><\/pre>\n\u00c9tape 4 : Soumettez votre site \u00e0 la liste de pr\u00e9chargement HSTS<\/h3>\n
\u00c9tape 5. V\u00e9rifiez votre en-t\u00eate Strict-Transport-Security<\/h3>\n
![\"Page](\"https:\/\/kinsta.com\/wp-content\/uploads\/2021\/12\/google-chrome-devtools.png\")