Mixed content HTTPS : repérer l'erreur et la corriger

Mixed content : de quoi parle-t-on ?

Une page web n'est jamais un fichier unique. Images, feuilles de style, scripts, polices, vidéos : chaque élément qu'elle appelle possède sa propre URL. Il suffit qu'une seule de ces ressources vienne d'une adresse en http://, alors que la page est servie en HTTPS, pour qu'on parle de contenu mixte (mixed content, en anglais).

Tout l'intérêt du HTTPS, c'est de chiffrer l'échange entre le visiteur et votre serveur, grâce au certificat SSL. Qu'une ressource échappe au chiffrement, et la brèche est ouverte : sur un Wi-Fi public, par exemple, quelqu'un placé sur le réseau peut la lire ou la modifier. D'où la méfiance du navigateur, qui juge la page partiellement sécurisée, voire dangereuse.

Contenu mixte passif : images, audio, vidéo

Côté passif, on range les éléments incapables de modifier le reste de la page : une image, un fichier audio, une vidéo. Aucun risque ? Pas tout à fait, puisqu'un attaquant pourrait remplacer votre logo, mais il reste limité. Les navigateurs récents tentent souvent de basculer ces fichiers en HTTPS d'eux-mêmes, et les bloquent quand ça échoue.

Contenu mixte actif : scripts, CSS, iframes

Autrement plus grave, le mixte actif. Chargés en HTTP, un script JavaScript, une feuille de style ou une iframe peuvent réécrire toute la page, siphonner un formulaire ou rediriger le visiteur vers un autre site. Voilà pourquoi la plupart des navigateurs le bloquent purement et simplement, sans laisser le choix à personne.

Comment Chrome, Firefox et Safari réagissent

Sur le fond, Chrome, Firefox et Safari suivent la même logique, à quelques nuances d'affichage près. L'actif ? Bloqué. Pour le passif, ils essaient en général de passer l'adresse en HTTPS, puis affichent un avertissement (ou retirent le cadenas) si la ressource reste en HTTP.

Pour un dirigeant, l'effet visible se résume souvent à trois symptômes. D'abord, le cadenas disparaît ou s'affiche barré. Ensuite, des éléments manquent : une image, un carrousel, un bouton de paiement. Et quand c'est un fichier CSS qui a sauté, la mise en page casse. Soyons francs : un visiteur qui lit « Non sécurisé » à côté de votre adresse a peu de chances de remplir votre formulaire de devis.

Repérer les ressources posant problème

Avant de toucher à quoi que ce soit, dressez la liste des ressources fautives. Je vous conseille d'avancer page par page : une seule d'entre elles peut contenir plusieurs requêtes de contenu mixte.

Étape 1 : ouvrir l'onglet Console

Clic droit sur la page, « Inspecter », puis onglet « Console » : voilà le chemin dans Chrome. Les requêtes de contenu mixte y apparaissent en jaune ou en rouge, accompagnées d'un message du type « Mixed Content: The page at … was loaded over HTTPS, but requested an insecure resource ». L'URL à corriger figure à la fin du message. Sous Firefox ? Même console, accessible avec le raccourci F12.

Étape 2 : vérifier l'onglet Réseau et le cadenas

Toutes les requêtes de la page sont listées dans l'onglet Réseau des outils de développement. Filtrez sur « http: » et les ressources non chiffrées sautent aux yeux. Un clic sur le cadenas de la barre d'adresse complète le tableau, puisque le navigateur y précise si la connexion est entièrement sécurisée ou non.

Étape 3 : passer tout le site en revue

À la main, ça passe pour quelques pages. Sur un site de plusieurs centaines d'URL, prenez plutôt un outil d'exploration capable de signaler les ressources en HTTP. La Google Search Console fait parfois remonter des soucis de sécurité, c'est vrai, mais elle ne remplace pas un vrai passage en revue.

Corriger le contenu mixte, dans le bon ordre

Une seule règle : chaque ressource doit être appelée en HTTPS. Reste à savoir où se cache l'adresse fautive (dans le code, dans la base de données ou chez un service externe), car la méthode en dépend.

Remplacer les URL en dur

Ouvrez le code ou le contenu de la page, puis remplacez http:// par https:// dans chaque attribut src ou href concerné. Un réflexe avant cela : collez la nouvelle URL dans votre navigateur pour vérifier que la ressource existe bien en HTTPS. Le service tiers ne le propose pas ? Hébergez le fichier vous-même, ou changez de fournisseur.

Sur WordPress : base de données et plugin

Articles, widgets, réglages du thème : sur WordPress, les vieilles adresses se nichent un peu partout. Première chose à faire, mettre à jour l'adresse du site dans les réglages généraux. Un plugin de recherche-remplacement se chargera ensuite de modifier les URL dans toute la base de données. Sauvegardez avant ! Une simple faute de frappe touche tout le site d'un coup. Et tant que vous y êtes, revoyez les autres bonnes pratiques pour sécuriser WordPress.

Ajouter la directive upgrade-insecure-requests

Parmi les directives de l'en-tête Content-Security-Policy, une se révèle très utile : upgrade-insecure-requests. Son rôle ? Demander au navigateur de charger automatiquement en HTTPS toute ressource appelée en HTTP. Sur un serveur Apache, elle s'ajoute dans le fichier .htaccess avec la ligne Header set Content-Security-Policy upgrade-insecure-requests. La content-security-policy et les autres réglages vous intéressent ? Notre guide des headers de sécurité HTTP va plus loin.

Ne vous y trompez pas : upgrade-insecure reste un filet de sécurité, pas une correction de fond. Une ressource absente en HTTPS sera bloquée malgré tout. Conservez aussi une redirection 301 de toutes vos pages HTTP vers HTTPS, pour que visiteurs et Google tombent toujours sur la bonne version.

Ce qui fait varier le temps de correction

Combien de temps faut-il ? Honnêtement, aucune durée type : tout dépend de l'état du site. Voici les facteurs qui pèsent le plus.

• Le volume de pages et de ressources concernées : quelques images, ou des milliers de liens enfouis dans d'anciens articles.
• L'emplacement des adresses : un fichier de thème se corrige vite, alors que des réglages éparpillés dans les extensions demandent plus de temps.
• Les services externes : face à un vieux lecteur vidéo ou à un widget sans version HTTPS, il faut trouver une solution de remplacement.
• L'accès au serveur : pas d'accès au fichier .htaccess ni aux en-têtes ? Il faudra passer par l'hébergeur.
• La qualité du code : plus un site est mal documenté, plus chaque modification exige de recherches.

Pour une petite entreprise, le plus simple consiste souvent à intégrer ce contrôle à la maintenance du site web : aucune nouvelle ressource en HTTP ne se glissera alors lors d'une mise à jour. Votre site accumule ce genre de soucis ? Une refonte de site internet peut revenir moins cher que des corrections à répétition. Chez RankerSquare, comptez dès 19,90 € par mois en abonnement pour un site vitrine sur-mesure ; les corrections sur un site existant se font sur devis.

Questions fréquentes