Avertissement de contenu mixte après l’activation de HTTPS

Ce que signifie cette erreur et comment la reconnaître

• L’adresse de la page utilise HTTPS, mais les outils de développement du navigateur signalent du contenu mixte.
• Un script, une feuille de style, une police, une image, une vidéo, une image d’arrière-plan ou une frame intégrée ne se charge pas ou se comporte différemment après l’activation de HTTPS.
• Des messages de la Console identifient une ressource HTTP demandée par une page HTTPS.
• Certaines fonctionnalités de la page sont incomplètes parce qu’un contenu actif, comme JavaScript ou CSS, est bloqué.
• L’avertissement apparaît uniquement sur certaines pages, certains templates ou pour certains états utilisateur, ce qui suggère une référence codée en dur ou générée sous condition.
• Le certificat du site semble valide pour la page principale, même si certaines ressources utilisent encore des références non sécurisées.

Causes principales, classées par probabilité

1. Références HTTP codées en dur : le contenu des pages, les templates, les fichiers de thème, les widgets ou les feuilles de style pointent encore vers une ressource dont l’adresse commence par http://.
2. Ancien contenu enregistré : des images, contenus intégrés, champs multimédias, scripts ou autres valeurs de la base de données ont conservé des références HTTP datant d’avant la migration vers HTTPS.
3. Sortie d’un thème ou d’un plugin : un composant génère une URL non sécurisée alors que l’adresse principale du site est configurée pour HTTPS.
4. Ressources externes sans prise en charge de HTTPS : un script, une police, une frame, un fichier multimédia ou une autre dépendance tierce peut ne pas être disponible de manière sécurisée.
5. Fichiers mis en cache ou regroupés : les caches de pages, bundles d’assets, fichiers minifiés, CDN ou reverse proxies peuvent encore fournir du contenu contenant une ancienne référence.
6. Configuration obsolète de l’application ou des assets : l’application peut construire des URL absolues à partir d’une ancienne adresse de base ou d’un ancien paramètre d’environnement.

Un avertissement de contenu mixte ne signifie pas, à lui seul, que le certificat du site est invalide. Une erreur de certificat concerne la connexion sécurisée au site ou à l’hôte de la ressource ; le contenu mixte concerne les ressources non sécurisées demandées au sein d’une page par ailleurs sécurisée.

Comment corriger le problème

1. Confirmer qu’il s’agit bien de contenu mixte

Ouvrez la page concernée dans un navigateur récent et ouvrez ses outils de développement. Dans la Console, recherchez les messages de contenu mixte. Dans le panneau Network, examinez la requête identifiée dans l’avertissement et notez son URL, son type de ressource, son statut et, lorsque cette information est affichée, le fichier ou le composant à l’origine de la requête.

Si le navigateur ne parvient pas à établir une connexion sécurisée au site principal et affiche un avertissement de certificat, traitez ce problème séparément. Ne modifiez pas les paramètres du certificat pour corriger une référence de ressource non sécurisée.

2. Identifier toutes les références non sécurisées

Examinez la page rendue et, lorsque cela est pertinent, son code source, ses feuilles de style, ses scripts et ses fichiers d’assets générés afin d’y rechercher des références HTTP. Ne vérifiez pas uniquement les images visibles : JavaScript, CSS, polices, frames, médias et images d’arrière-plan CSS peuvent également provoquer des avertissements ou des échecs de chargement.

Testez la page concernée dans une fenêtre de navigation privée ou après avoir vidé le cache pertinent du navigateur. Cela aide à distinguer une requête non sécurisée actuelle d’une ancienne réponse mise en cache, mais ne remplace pas la correction de la référence d’origine.

3. Localiser la source qui génère la référence

Utilisez le type de ressource et les pages concernées pour déterminer d’où provient l’URL :

• Un seul article ou une seule page : examinez son contenu enregistré ou son champ multimédia.
• Plusieurs pages utilisant une même mise en page : examinez le template partagé, le thème, le widget ou le composant réutilisable.
• Uniquement les pages utilisant une fonctionnalité : examinez le plugin, l’intégration, le contenu intégré ou le paramètre de configuration concerné.
• Une requête portant sur un asset combiné : examinez la feuille de style source, le script, le processus de build, le cache ou le proxy ayant produit le bundle.
• Un comportement différent pour les visiteurs connectés et déconnectés : comparez les couches de contenu et de cache rendues pour chaque état.

4. Mettre à jour la référence à sa source

Appliquez la correction correspondant à l’emplacement où la référence est stockée :

• Modifiez le contenu de la page ou de l’article afin d’utiliser la version HTTPS de la ressource.
• Mettez à jour le paramètre du site, du média, du thème, du plugin, du contenu intégré ou de l’intégration qui génère l’URL.
• Corrigez les références codées en dur dans les templates, feuilles de style, scripts ou fichiers de configuration.
• Pour une ressource du même site, utilisez un chemin relatif pris en charge lorsque cette solution convient à la structure de l’application et du déploiement.
• Pour une ressource externe, vérifiez que son hôte prend en charge HTTPS. Si ce n’est pas le cas, remplacez la dépendance par une source sécurisée ou supprimez-la, en particulier lorsqu’elle fournit du contenu actif.

5. Utiliser le remplacement en masse avec des précautions

Le remplacement en masse convient lorsque la même valeur obsolète est enregistrée dans un grand nombre d’enregistrements connus. Avant de modifier les données de production, obtenez une autorisation, créez une sauvegarde restaurable, définissez précisément la portée de l’opération et testez-la si possible sur une copie de staging ou sur des enregistrements représentatifs.

Tenez compte des données sérialisées ou structurées et évitez de remplacer aveuglément toutes les occurrences d’une chaîne de texte. Examinez les hôtes externes, les redirections, les chemins de fichiers, les valeurs de configuration et les enregistrements dont le texte http:// n’est peut-être pas une URL de page. Si vous ne connaissez pas bien la structure des données, demandez à l’administrateur de l’application ou à un développeur d’effectuer la modification.

6. Vider les contenus générés et mis en cache

Après avoir corrigé la source, purgez les caches de l’application, des pages, du CDN, du reverse proxy et du navigateur susceptibles de contenir encore d’anciens contenus HTML ou bundles d’assets. Régénérez les assets regroupés ou minifiés si le site en utilise. Effectuez uniquement les purges de cache autorisées pour l’environnement concerné, car elles peuvent temporairement augmenter le trafic vers l’origine ou modifier le comportement du site.

7. Vérifier la correction

Rechargez les pages concernées et consultez à nouveau la Console et le panneau Network. Vérifiez que la ressource précédemment signalée est demandée de manière sécurisée, que les scripts et les styles fonctionnent et qu’aucune nouvelle référence non sécurisée n’apparaît.

Répétez la vérification sur les templates associés ainsi que sur les vues pertinentes pour les visiteurs connectés et déconnectés. Si l’avertissement réapparaît après l’actualisation du cache, le template, le plugin, la configuration ou l’asset généré sous-jacent doit encore être corrigé.

Prévention et vérification du correctif

• Ajoutez les images, scripts, feuilles de style, polices, contenus intégrés et médias en utilisant des références compatibles avec HTTPS.
• Maintenez la cohérence entre l’adresse du site de l’application, les paramètres des assets, le thème, les plugins et les intégrations avec HTTPS.
• Examinez les dépendances tierces avant le déploiement et remplacez les fournisseurs qui ne proposent pas de diffusion sécurisée.
• Intégrez des vérifications du contenu mixte aux tests de staging et aux tests réalisés après une migration.
• Inspectez les templates partagés et les composants réutilisables, et pas uniquement la page où l’avertissement a été découvert.
• Conservez des sauvegardes testées avant toute modification en masse du contenu, puis purgez ou régénérez les caches et bundles d’assets concernés.
• Vérifiez à nouveau les pages avec différents états d’authentification lorsqu’elles rendent des ressources différentes.

Questions fréquentes