![10 erreurs d’implémentation HTTPS [Étude Semrush]](https://static.semrush.com/blog/uploads/media/cc/9c/cc9cd0d682279ca500f169f0663f481a/test-template-01.svg)
Faire passer votre site en HTTPS n’est pas un bonus SEO ni l’apanage des grandes entreprises, c’est un must pour tout type de sites. Le volume de trafic crypté augmente tous les ans et, selon la télémétrie Firefox, le 29 janvier 2017, la moitié du trafic internet était sécurisé : c’est considérable !
La signification de ce point de basculement ne peut vraiment pas être exagérée.
Si votre site web est toujours du « mauvais côté », vous devriez remettre en question votre perception du trafic crypté. L'utilisation du HTTPS est un signal fort de positionnement, c’est un signal de confiance augmentant votre crédibilité auprès des utilisateurs, et enfin c’est une façon sûre de protéger les données de votre site contre certains types d’attaques.
Aujourd’hui, nous allons parler des erreurs qui peuvent survenir durant une implémentation HTTPS et des façons de les réparer et de les éviter. Ainsi, si vous avez déjà fait passer votre site en HTTPS ou que vous pensez à le faire, cet article vous aidera à éviter les pièges les plus courants.
Erreurs d’implémentation HTTPS
Toutes les données statistiques pour cet article ont été obtenues par une recherche en utilisant l’outil Site Audit de SEMrush. Nous avons rassemblé des données anonymes de 100 000 sites web pour déterminer la fréquence des erreurs d’implémentation HTTPS. Tout d’abord, nous devons préciser que seuls 45 % des sites web analysés prenaient en charge le HTTPS et toutes les données relatives à la fréquence des erreurs liées au HTTS ont été recueillies durant l’analyse de ces domaines sécurisés.
Google a clairement spécifié les pièges courants liés au HTTPS qui peuvent survenir et qui doivent être évités. Regardons maintenant plus en détail chacun d’eux et examinons minutieusement comment ces erreurs peuvent se produire.
Pages non sécurisées avec des entrées de mot de passe
À partir de janvier 2017 (Chrome 56), nous allons signaler comme non sécurisées les pages HTTP qui reçoivent des mots de passe ou des cartes de crédit ; cela fait partie d’un plan sur le long terme dont l’objectif est de signaler tous les sites HTTP comme non sécurisés.
Pour déterminer la fréquence de cette erreur, nous avons analysé l’ensemble des 100 000 domaines, car Google a des exigences strictes sur les pages « non sécurisées » : toute page qui recueille un mot de passe doit être encryptée. Nous espérons que cette initiative facilitera l’expansion du HTTTPS. En effet, aujourd’hui, 9 % des sites analysés ont encore des pages non sécurisées qui demandent un mot de passe.
Problèmes d’architecture de site
Contenu mixte
Il s'agit du contenu mixte quand une page se charge sur des connexions HTTPS sécurisées, mais contient des éléments (comme des images, des liens, des Iframes, des scripts, etc.) qui ne sont pas sécurisés par le protocole HTTPS.
D’abord, cela peut conduire à des problèmes de sécurité. Ensuite, les navigateurs préviendront les internautes qu’ils sont sur le point de charger du contenu non sécurisé, ce qui peut avoir une influence négative sur l’expérience utilisateur et diminuer la confiance qu’on accorde à votre site.
L’étendue de ce problème est plus grande que vous ne pouvez l’imaginer : 50 % des sites sont touchés. Il faut savoir qu’évaluer manuellement la présence et l’étendue du problème est très chronophage, car un site peut contenir des centaines de pages. Cela fait du contenu mixte un véritable défi.
Liens internes sur un site HTTPS pointant vers des pages HTTP
Tous les liens internes de site, les images, les scripts, etc. doivent pointer vers des versions HTTPS. C’est extrêmement important, en particulier s’il n’y a pas d’implémentation de redirections ou de HSTS. Mais il est de toute façon préférable de remplacer les liens par des versions HTTPS même si des redirections sont implémentées. C’est également une erreur qui peut se produire quand on fait passer un site en HTTPS. Il semble d’ailleurs que ce soit le problème le plus important, puisqu’il est chronophage en raison du nombre de pages qui doivent être analysées : 50 % des sites que nous avons analysés doivent faire face à cet écueil.
Pas de redirections ou de canonicals aux URLs HTTPS
Quand vous faites passer votre site de HTTP en HTTPS, il est important de rediriger correctement les pages canoniques. Et ce, pour plusieurs raisons : avant tout, pour assurer une expérience du site sécurisée et stable, c’est une évidence. Ensuite, la coexistence de pages HTTP non connectées à des HTTPS ne nuit pas à votre SEO. Les moteurs de recherche ne sont pas en mesure de comprendre quelle page doit être indexée et laquelle doit être priorisée dans les résultats de recherche. Par conséquent, vous pouvez tomber sur de nombreux problèmes, y compris des pages entrant en compétition les unes avec les autres, une perte de trafic et un mauvais positionnement dans les résultats de recherche.
Des redirections ou des URLs canoniques correctement implémentées peuvent améliorer le positionnement d’un site en combinant tous les signaux.
Ce problème ne nuit pas aux sites utilisant le HSTS, parce que ce dernier empêche la communication des navigateurs sur le HTTP ; c’est pourquoi nous ne les avons pas pris en compte durant notre recherche. Nous avons donc découvert que sur 8 % des sites que nous avons analysés (en excluant ceux qui prennent en charge le HSTS), la home page ne correspond pas à la version HTTPS. Et nous ne parlons que des home pages... Vous pouvez imaginer le nombre de pages du reste des sites qui n’ont pas été correctement redirigées.
URLs HTTP dans le sitemap.xml pour un site HTTPS
Encore une fois, cette erreur peut facilement se produire lors du passage d’un site en HTTPS.
Pour empêcher Google de rendre indûment une page HTTP canonique, vous devriez éviter les pratiques suivantes : inclure la page HTTP dans vos entrées sitemap ou hreftlang plutôt que la version HTTPS.
Bien que ce soit une exigence clairement spécifiée, 5,5 % des sites web font cette erreur. En faisant passer votre site en HTTPS, vous n’avez pas besoin de créer un autre fichier sitemap.xml HTTPS : il suffit de changer le protocole HTTPS dans le sitemap.
Pour apprendre à migrer correctement votre site en HTTPS, consultez ce guide de Fili Wiese (en anglais).
Erreurs de certificat de sécurité
Certificat SSL expiré
Un certificat SSL (Secure Socket Layer certificate) est utilisé pour établir une connexion sécurisée entre un serveur et un navigateur, ainsi que pour empêcher que des données de votre site ne soient volées. Pour certains types d’activités qui travaillent avec des données confidentielles, comme des cartes de crédit de clients et des numéros de sécurité sociale, un certificat SSL expiré entraîne un risque de perte de crédibilité. En plus, un certificat expiré provoque le surgissement d’un message de mise en garde pour les utilisateurs qui entrent sur votre site, ce qui a évidemment une influence négative sur votre taux de rebond. Durant notre recherche, nous avons trouvé que 2 % des sites analysés ont des certificats SSL expirés.
Certificat SSL enregistré avec un nom de domaine incorrect
Cette erreur se produit quand le nom du domaine pour lequel votre certificat SSL est émis ne correspond pas au nom de domaine affiché sur la barre d’adresse. Cette erreur d’inadéquation apparaît sur 6 % des sites web analysés.
La fréquence plus élevée de cette erreur, en comparaison avec la précédente, peut être expliquée par l’idée fausse selon laquelle un certificat SSL émis seulement pour le domaine racine (exemple.com) marche pour les sous-domaines (info.exemple.com). C’est une erreur même dans le cas où le certificat est correctement installé. Par exemple, si le certificat SSL d’un site est émis pour www.exemple.com, l’utilisateur, en entrant exemple.com, tombera bien sur le site mais en recevant une notification d’erreur.
Ce problème peut être résolu en utilisant un certificat multidomaine, qui vous permet d’utiliser un seul certificat pour des noms de domaine ou des adresses IP multiples. Notez que les noms non qualifiés (www), les noms locaux (localhost), ou les adresses IP privées violent les spécifications du certificat.
Problèmes du serveur
Pas de prise en charge de serveur HTST (HTTP Strict Transport Security)
Le protocole HSTS informe les navigateurs qu’ils ne peuvent communiquer avec les serveurs que par des connexions HTTPS sécurisées. Admettons qu’un utilisateur tape dans la barre d’adresse le nom de votre site (http://exemple.com), HSTS demandera alors au navigateur d’utiliser la version HTTPS.
HSTS est une protection contre les attaques par abaissement de version (downgrade attacks) et récupération de cookie de session d’un internaute (cookie hijacking). C’est une façon de protéger les utilisateurs d’une attaque de l’homme-au-milieu (man-in-the-middle).
Un attaquant man-in-the-middle essaie d’intercepter le trafic provenant d’un utilisateur dont le certificat est invalide et espère que l’utilisateur acceptera le mauvais certificat. HSTS ne permet pas à l’utilisateur de passer outre le message de certificat invalide.
86 % des sites web analysés ne prennent pas en charge le HSTS. Ça n’a rien d’étonnant : cette technologie vient de sortir et les navigateurs ne font que commencer à la prendre en charge. On peut espérer voir les choses s’améliorer l’année prochaine.
Ancienne version du protocole de sécurité (TLS 1.0 ou plus ancien)
Les protocoles Transport Layer Security (TLS) et Secure Sockets Layer (SSL), qui assurent une connexion sécurisée entre un site et un navigateur, doivent être régulièrement mis à jour vers de nouvelles versions fortes : 1,1 ou plus. Il n’y a pas à hésiter, c’est une obligation. Une version dépassée du protocole rend très facile le vol de vos données. C’est une des erreurs les plus graves, et néanmoins on la trouve sur 3,6 % des sites web analysés. Cela veut dire que même les entreprises qui font attention à bien prolonger leur certificat SSL peuvent oublier de mettre à jour les versions de leur protocole. Alors, n’oubliez pas de vérifier l’état actuel de votre site.
Pas de prise en charge SNI (Server Name Indication)
La Server Name Indication (SNI) est une extension du protocole TLS (Transport Layer Security), elle vous permet de prendre en charge des certificats serveurs et hébergeurs multiples à la même adresse IP.
L’utilisation de la SNI résout le problème que nous avons abordé plus haut : celui du certificat SSL enregistré avec un nom de domaine incorrect. Admettons que vous avez ajouté un nouveau sous-domaine : en l’entrant, votre utilisateur recevra une mise en garde sur la connexion non sécurisée, car le certificat SSL est émis pour un nom de domaine différent. Et il est difficile, voire impossible, de prévoir tous les noms possibles. Voilà donc à quoi sert la SNI : à empêcher cette erreur.
Ce n’est pas une exigence stricte, et c’est probablement pour ça que des erreurs liées à la SNI n’ont été détectées que sur 0,56 % des sites que nous avons analysés.
À propos du rapport SEMrush d’implémentation HTTPS
Toutes les erreurs dont nous avons parlé peuvent être détectées par le rapport SEMRush d’implémentation HTTPS : un nouveau rapport disponible via l’outil SEMrush Site Audit. Nous voudrions maintenant ajouter quelques mots sur la réalisation technique de ce rapport et la façon dont il peut détecter toutes vos erreurs HTTPS.
Quand il détecte des erreurs liées à un certificat SSI expiré, le rapport SEMrush d’implémentation HTTPS ne vous montre pas seulement le statut d’expiration du certificat, mais aussi la date de son expiration. En plus, il peut aider à éviter ce problème en envoyant à l’avance une notification sur l’expiration prochaine du certificat.
Si un certificat est enregistré avec un nom de domaine incorrect, le rapport vous montrera le sous-domaine pour lequel le certificat est émis, ce qui vous aidera à prendre conscience du problème rapidement.
En ce qui concerne les problèmes liés au serveur, le rapport vous fournira des informations complètes sur le sous-domaine qui a besoin d’une mise à jour du protocole de sécurité (indiquant la version actuelle) ou d’une implémentation d’un support HSTS et SNI.
En ce qui concerne les problèmes liés à l’architecture du site, une des vérifications les plus intéressantes du rapport concerne le contenu mixte détecté sur une page. Le rapport trouvera tous les types d’éléments HTTP que nous extrayons d’une balise. Ce qui veut dire que le rapport est conçu pour trouver et spécifier absolument tout élément non sécurisé. Sachant à quel point l’exploration du contenu mixte peut être chronophage, ce rapport vous sera assurément d’une grande aide.
Il y a aussi un logo de niveau de gravité pour toutes les erreurs, ce qui vous aidera à établir vos priorités pour travailler d’abord sur les problèmes les plus importants, et vous occuper des autres ensuite.
On peut donc dire que ces toutes dernières implémentations, ainsi que la grande vitesse de crawl, les 50 vérifications additionnelles de SEO on page et technique et son interface conviviale font de l’outil SEMrush Site Audit un des auditeurs de site les plus performants du marché, et sans aucun doute la meilleure des boîtes à outils SEO.
Si vous voulez avoir un peu plus d'informations sur le sujet, voici la présentation de ma collègue Natalia qui a abordé ce sujet lors de sa conférence à QueDuWeb :
Qu’est-ce que vous en pensez ? Partagez vos pensées sur notre nouveau rapport et faites-nous savoir quelles erreurs HTTPS vous ont causé le plus de problèmes et la manière dont vous les avez surmontés.