Ce que « contenu mixte » signifie et pourquoi le navigateur a bloqué votre image

Vous avez chargé une page via HTTPS, le cadenas est dans la barre d’adresse, et pourtant une image manque, un script ne s’est pas exécuté, ou tout un widget n’a pas pu apparaître. Ouvrez la console et le message est là : « Contenu mixte : la page a été chargée via HTTPS, mais a demandé une ressource non sécurisée via HTTP. Cette requête a été bloquée. »

La page est sécurisée. Quelque chose qu’elle a demandé ne l’était pas, et le navigateur a refusé de la récupérer. C’est tout ce qu’est une erreur de contenu mixte, et la correction est généralement un seul caractère - mais il est utile de comprendre pourquoi le navigateur est si strict concernant une seule image manquante.

Ce que « mixte » signifie ici

Une page servie via HTTPS est livrée chiffrée, et le cadenas est une promesse au visiteur que tout ce qui s’y trouve est arrivé de cette manière. Ensuite, la page demande une ressource - une image, un script, une feuille de style, une police - en utilisant une adresse en http:// ordinaire. Cette ressource arriverait non chiffrée, via une connexion que n’importe qui sur le réseau peut lire ou altérer.

C’est le mélange : une page sécurisée et une requête non sécurisée dedans. Le navigateur ne brisera pas silencieusement la promesse que le cadenas a faite, donc il intervient. Ce qu’il fait ensuite dépend de la dangerosité de la ressource.

Bloqué ou juste avertissement

Le contenu mixte n’est pas tous traité de la même manière, et c’est cette partie qui explique pourquoi parfois une image se charge avec un avertissement et parfois un script disparaît entièrement.

Le contenu actif est bloqué catégoriquement. Les scripts, les feuilles de style, les iframes et tout ce qui peut modifier la page ou exécuter du code. Si l’un de ces éléments est demandé via HTTP, le navigateur refuse complètement de le charger, car un script altéré pourrait réécrire la page entière. C’est celui qui casse les fonctionnalités : un widget de paiement, une balise d’analyse, une carte qui n’apparaît jamais.

Le contenu passif est chargé, avec un avertissement, ou amélioré. Les images, vidéos et audio - les choses qui s’affichent mais ne peuvent pas exécuter du code. Les navigateurs plus anciens chargeaient ceux-ci via HTTP et dégradaient le cadenas pour vous avertir. Les navigateurs modernes essaient de plus en plus de les récupérer via HTTPS à la place, et ne s’arrêtent visiblement que si cela ne fonctionne pas. Donc une image manquante et un script mort sont souvent le même problème sous-jacent, se montrant avec une gravité différente.

Comment le trouver et le corriger

La console nomme la ressource exacte. Lisez l’URL dont elle se plaint, et la correction est presque toujours de demander cette ressource via https:// au lieu de http://.

• Si la ressource a une version HTTPS, utilisez-la. La plupart en ont une ; changer http:// en https:// dans votre propre balisage est la correction complète. Si vous en avez beaucoup, une adresse relative au protocole //example.com/... ou une directive upgrade-insecure-requests de content-security-policy les corrige en masse.
• Si la ressource n’a pas de version HTTPS, vous ne pouvez pas l’inclure. Un bien tiers servi uniquement via HTTP doit être remplacé, proxyfié via votre propre serveur HTTPS, ou supprimé. Il n’y a aucun paramètre du navigateur qui rend cela sûr, et dire à un visiteur de désactiver la protection n’est pas une correction.
• Faites attention à cela dans les données, pas seulement dans le balisage. Une URL stockée dans votre base de données, renvoyée par une API, ou collée dans un champ de texte riche est la raison habituelle pour laquelle le contenu mixte persiste après une migration vers HTTPS : les modèles ont été corrigés mais le contenu ne l’a pas été.

Une requête qui échoue de cette manière ressemble beaucoup à une qui a échoué pour d’autres raisons, c’est pourquoi la ligne de console est importante. Si la console dit plutôt que la requête a été bloquée par la politique CORS, ou revient sous forme de TypeError : Impossible de récupérer, c’est un problème différent avec une correction différente - le premier mot de l’erreur fait beaucoup de travail.

Pourquoi une capture d’écran ne suffit pas pour en signaler une

Une défaillance de contenu mixte est invisible dans une capture d’écran : la page a juste un vide où quelque chose devrait être, et la raison vit dans la console, que la personne qui la signale n’a presque certainement pas ouverte. « L’image manque » et « le widget de paiement n’a pas chargé » sont les rapports que vous recevez, et aucun ne contient la ligne de console qui dit exactement quelle ressource HTTP sur une page HTTPS a été refusée.

Le journal de la console qu’il capture est l’endroit où vit le message de contenu mixte, ressource nommée et tout, donc quiconque récupère le rapport peut voir quelle URL non sécurisée corriger sans avoir à reproduire la page et ouvrir les outils de développeur pour la trouver.

En un paragraphe

Le contenu mixte est une ressource non sécurisée http:// demandée par une page sécurisée https://, et le navigateur la bloque - complètement pour les scripts et autres contenus actifs, plus doucement pour les images - plutôt que de briser la promesse que le cadenas fait. La correction est presque toujours de demander la ressource via HTTPS, dans votre balisage et dans vos données stockées ; si elle n’a pas de version HTTPS, elle ne peut pas être incluse en toute sécurité du tout. Et parce que la défaillance est un vide silencieux sur la page avec la raison cachée dans la console, il vaut la peine de la capturer plutôt que de la décrire.