À la une
Plugins abandonnés : repérer ceux qui deviennent une porte d’entrée- Plugin de sécurité WordPress : ce qu’il apporte et ce qu’il alourdit
- Attaques par force brute sur la page de connexion : les bloquer efficacement
- Double authentification sur l’admin : la mesure la plus rentable
- Mises à jour automatiques WordPress : lesquelles activer sans risque
- Sauvegarder un site : fréquence, emplacement et test de restauration
Une erreur de contenu mixte (mixed content) apparaît lorsqu’une page chargée en HTTPS appelle au moins une ressource (image, script, feuille de style) via le protocole HTTP non chiffré. Selon la documentation Mozilla Developer Network, les navigateurs modernes bloquent alors tout ou partie de ces ressources, ce qui casse l’affichage, supprime le cadenas de la barre d’adresse et dégrade la confiance des visiteurs.
Le problème survient le plus souvent juste après la migration d’un site vers HTTPS : le certificat SSL est bien installé, mais des dizaines d’URL internes pointent encore vers http://. Corriger ces appels demande de la méthode, pas de la chance. Cet article détaille chaque étape, de la détection à la prévention.
Dans cet article
- Le contenu mixte se divise en deux catégories : actif (scripts, iframes) bloqué par défaut et passif (images, vidéos) parfois toléré avec avertissement
- La console du navigateur (DevTools) liste chaque ressource fautive avec son URL complète et son numéro de ligne
- Sur WordPress, un rechercher-remplacer dans la base de données corrige 80 à 95 % des URL en une seule opération
- L’en-tête Content-Security-Policy: upgrade-insecure-requests force la réécriture côté client sans modifier le code source
- Un audit régulier avec un crawler détecte les régressions avant qu’elles n’atteignent les visiteurs
- La directive HSTS (HTTP Strict Transport Security) empêche tout retour accidentel vers HTTP
Sommaire
- Ce que signifie l’erreur Mixed Content et pourquoi le navigateur la bloque
- Contenu mixte actif ou passif : deux niveaux de risque à distinguer
- Repérer chaque ressource HTTP : trois méthodes complémentaires
- Corriger les URL en dur dans la base de données WordPress
- Forcer le HTTPS côté serveur : .htaccess, en-têtes CSP et HSTS
- Cas particuliers : polices externes, iframes et scripts tiers
- Vérifier que le cadenas revient : les outils de contrôle final
- Prévenir le retour du contenu mixte sur le long terme
Ce que signifie l’erreur Mixed Content et pourquoi le navigateur la bloque
Le protocole HTTPS garantit que les données échangées entre le navigateur et le serveur sont chiffrées et authentifiées. Lorsqu’une page HTTPS charge une ressource via HTTP, cette ressource transite en clair sur le réseau. Un attaquant positionné entre le visiteur et le serveur (attaque dite man-in-the-middle) peut alors intercepter, modifier ou remplacer cette ressource sans que le navigateur ne le détecte.
Pour protéger l’utilisateur, Chrome, Firefox, Edge et Safari appliquent une règle simple : toute ressource HTTP appelée depuis une page HTTPS est considérée comme non sûre. Le navigateur affiche alors un avertissement dans la console, retire le cadenas vert (ou affiche un triangle d’alerte), et dans certains cas bloque purement et simplement le chargement de la ressource. La spécification technique est définie par le W3C dans le document Mixed Content Level 2.
Le message d’erreur typique dans la console ressemble à ceci :
Mixed Content: The page at 'https://example.com/page' was loaded over HTTPS,
but requested an insecure resource 'http://example.com/image.jpg'.
This request has been blocked; the content must be served over HTTPS.Ce n’est pas un problème de certificat ni de configuration serveur au sens strict : c’est un problème de contenu. Le certificat fonctionne, le serveur répond en HTTPS, mais le code HTML (ou la base de données) contient encore des références en http://.
Contenu mixte actif ou passif : deux niveaux de risque à distinguer
Les navigateurs ne traitent pas toutes les ressources mixtes de la même façon. La distinction repose sur le pouvoir de nuisance de la ressource si elle était compromise.
| Type | Ressources concernées | Comportement du navigateur | Niveau de risque |
|---|---|---|---|
| Contenu mixte actif | Scripts JS, feuilles CSS, iframes, requêtes XMLHttpRequest, polices web (via @font-face), objets Flash | Bloqué par défaut sur tous les navigateurs modernes | Critique : un script modifié peut voler des identifiants, injecter du contenu ou rediriger l’utilisateur |
| Contenu mixte passif | Images, vidéos, fichiers audio | Chargé avec avertissement (cadenas supprimé) ; Chrome bloque progressivement depuis la version 80 | Modéré : l’image peut être remplacée (défacement) mais ne peut pas exécuter de code |
En pratique, les deux types doivent être corrigés. Même le contenu passif supprime le cadenas, ce qui envoie un signal négatif aux visiteurs et peut affecter le taux de conversion. Google considère par ailleurs le HTTPS comme un signal de classement depuis 2014, et un site qui affiche des avertissements de sécurité perd en crédibilité auprès des moteurs de recherche.
Voir aussi Plugin de sécurité WordPress : ce qu’il apporte et ce qu’il alourdit
Repérer chaque ressource HTTP : trois méthodes complémentaires
Avant de corriger, il faut dresser la liste exhaustive des ressources fautives. Trois approches se complètent.
Méthode 1 : la console du navigateur (DevTools)
Ouvrir les outils de développement (touche F12 sur Chrome ou Firefox), puis l’onglet Console. Chaque erreur de contenu mixte y apparaît avec l’URL complète de la ressource et la ligne du code source qui l’appelle. C’est la méthode la plus rapide pour une page isolée, mais elle ne couvre qu’une seule page à la fois.
Méthode 2 : un crawler qui parcourt tout le site
Des outils comme Screaming Frog (version gratuite jusqu’à 500 URL) ou le module d’audit de Sitebulb parcourent l’ensemble du site et listent toutes les ressources appelées en HTTP. Le rapport indique la page source, l’URL de la ressource et son type (image, script, CSS). Cette méthode est indispensable sur un site de plus de dix pages.
Méthode 3 : une recherche directe dans le code et la base de données
Sur un site WordPress, de nombreuses URL sont stockées dans la table wp_posts (contenu des articles) et wp_options (réglages). Une requête SQL ciblée identifie chaque occurrence :
SELECT ID, post_title
FROM wp_posts
WHERE post_content LIKE '%http://votredomaine.fr%';Dans les fichiers du thème et des extensions, une recherche avec grep depuis le terminal complète l’inventaire :
grep -rn "http://votredomaine.fr" /var/www/html/wp-content/Cette commande retourne chaque fichier et chaque ligne contenant une URL en HTTP. Elle permet de repérer les appels codés en dur dans un thème personnalisé ou dans un plugin obsolète qui n’a pas été mis à jour.
Corriger les URL en dur dans la base de données WordPress
Sur WordPress, la correction la plus efficace passe par un rechercher-remplacer global dans la base de données. L’opération remplace toutes les occurrences de http://votredomaine.fr par https://votredomaine.fr. Deux méthodes fiables existent.
Avec WP-CLI (méthode recommandée)
L’outil en ligne de commande WP-CLI effectue un remplacement sérialisé qui respecte la structure des données WordPress :
wp search-replace 'http://votredomaine.fr' 'https://votredomaine.fr' --all-tables --dry-runLe paramètre --dry-run simule l’opération et affiche le nombre de remplacements prévus sans modifier la base. Une fois le résultat vérifié, relancer la commande sans ce paramètre applique les changements. Il est impératif de réaliser une sauvegarde complète avant toute intervention sur la base de données.
Avec une extension dédiée
Pour les utilisateurs sans accès SSH, l’extension Better Search Replace offre une interface graphique dans le tableau de bord WordPress. Elle propose le même mécanisme de simulation (dry run) et gère correctement les données sérialisées des options et des widgets.
Après le remplacement, vider le cache du site est indispensable. Si un système de cache serveur ou CDN est en place, ses entrées doivent également être purgées pour que les nouvelles URL prennent effet immédiatement.
Les fichiers du thème et des extensions
Certaines URL en dur se trouvent dans les fichiers PHP, CSS ou JavaScript du thème. Elles n’apparaissent pas dans la base de données et doivent être corrigées manuellement. Les cas les plus fréquents :
- Un chemin d’image écrit en dur dans le fichier
header.phpoufooter.php - Une feuille de style appelée avec un
http://dansfunctions.php - Un script externe chargé sans protocole relatif dans un plugin de sécurité ou de statistiques
La bonne pratique consiste à utiliser des URL relatives au protocole (//votredomaine.fr/image.jpg) ou, mieux encore, la fonction WordPress esc_url() qui adapte automatiquement le protocole.
Forcer le HTTPS côté serveur : .htaccess, en-têtes CSP et HSTS
Corriger les URL dans le contenu ne suffit pas toujours. Des mesures côté serveur ajoutent une couche de protection supplémentaire et traitent les cas résiduels.
Redirection .htaccess (Apache)
La redirection globale de HTTP vers HTTPS dans le fichier .htaccess garantit que toute requête non chiffrée est renvoyée vers sa version sécurisée :
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]Sur Nginx, la directive équivalente se place dans le bloc server qui écoute le port 80 :
server {
listen 80;
server_name votredomaine.fr;
return 301 https://$host$request_uri;
}Cette redirection traite les requêtes directes vers le serveur, mais ne corrige pas les ressources appelées en HTTP depuis le code HTML. C’est là qu’intervient la Content Security Policy.
Content-Security-Policy : upgrade-insecure-requests
L’en-tête HTTP Content-Security-Policy: upgrade-insecure-requests demande au navigateur de réécrire automatiquement toutes les URL HTTP en HTTPS avant d’effectuer la requête. C’est un filet de sécurité efficace pendant la phase de migration :
Header always set Content-Security-Policy "upgrade-insecure-requests"Cette directive ne remplace pas la correction des URL dans le code source : elle masque le problème côté client. Si la ressource n’existe pas en HTTPS (serveur tiers sans certificat), la requête échouera silencieusement. Elle constitue cependant une solution transitoire précieuse sur les sites volumineux où le remplacement prend du temps.
HSTS : empêcher tout retour vers HTTP
L’en-tête Strict-Transport-Security indique au navigateur de ne plus jamais contacter le domaine en HTTP pendant une durée définie :
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"La valeur max-age=31536000 correspond à un an. Le paramètre includeSubDomains étend la règle à tous les sous-domaines. Le paramètre preload permet de soumettre le domaine à la liste HSTS Preload maintenue par les principaux navigateurs, ce qui applique la règle dès la première visite, avant même la première réponse du serveur.
Avant d’activer HSTS, s’assurer que toutes les ressources du domaine et de ses sous-domaines sont bien accessibles en HTTPS. Une erreur à ce stade rendrait certaines pages inaccessibles pendant toute la durée du max-age.
Cas particuliers : polices externes, iframes et scripts tiers
Certaines ressources mixtes ne proviennent pas du site lui-même mais de services tiers. Leur correction demande une approche spécifique.
Polices Google Fonts et autres CDN
Les anciennes intégrations de Google Fonts utilisaient parfois des URL en HTTP. La solution consiste soit à mettre à jour l’appel vers https://fonts.googleapis.com, soit à héberger les polices en local, ce qui élimine la dépendance externe et améliore la conformité RGPD.
Iframes de vidéos et de cartes
Les intégrations YouTube, Vimeo ou Google Maps fonctionnent toutes en HTTPS. Si une iframe utilise encore http://, il suffit de remplacer le protocole dans l’URL src. Les plateformes majeures redirigent automatiquement, mais le navigateur détecte l’appel initial en HTTP et génère l’avertissement avant la redirection.
Scripts de tracking et widgets
Certains outils d’analyse, de chat en ligne ou de publicité fournissent des snippets en HTTP. Trois cas de figure se présentent :
- Le service supporte HTTPS : remplacer
http://parhttps://dans le snippet - Le service propose un protocole relatif : utiliser
//cdn.service.com/script.js - Le service ne supporte pas HTTPS : le retirer du site ou trouver une alternative sécurisée, car il représente une faille permanente
Chaque script tiers constitue potentiellement un vecteur d’attaque. Un inventaire régulier des dépendances externes fait partie des bonnes pratiques de sécurisation d’un site WordPress.
Vérifier que le cadenas revient : les outils de contrôle final
Après les corrections, un contrôle systématique confirme que toutes les ressources sont désormais servies en HTTPS. Plusieurs outils gratuits facilitent cette vérification.
| Outil | Périmètre | Ce qu’il détecte | Coût |
|---|---|---|---|
| Console DevTools (F12) | Page par page | Erreurs mixtes, URL fautives, ligne de code | Gratuit |
| Why No Padlock | Page par page | Ressources HTTP, certificat, chaîne de confiance | Gratuit |
| Screaming Frog | Site entier (500 URL en version gratuite) | Toutes les ressources HTTP par page | Gratuit / 259 £/an |
| SSL Labs (Qualys) | Domaine | Configuration SSL/TLS, vulnérabilités, note globale | Gratuit |
| Chrome Lighthouse | Page par page | Bonnes pratiques HTTPS dans l’audit sécurité | Gratuit |
La vérification ne doit pas se limiter à la page d’accueil. Les erreurs de contenu mixte se cachent souvent dans les pages intérieures : articles anciens avec des images en HTTP, pages produits avec des scripts d’affiliation, pages de contact avec une iframe Google Maps obsolète. Un crawler reste le moyen le plus fiable de couvrir l’ensemble du site.
Sur un site dont la lenteur a déjà été diagnostiquée, l’audit de contenu mixte se combine naturellement avec l’analyse de performance : les ressources bloquées par le navigateur génèrent des erreurs réseau qui allongent le temps de chargement perçu.
Prévenir le retour du contenu mixte sur le long terme
Corriger le contenu mixte une fois ne garantit pas qu’il ne réapparaîtra pas. Chaque nouvel article, chaque mise à jour de plugin, chaque modification de thème peut réintroduire des URL en HTTP. Plusieurs mesures préventives réduisent ce risque à zéro ou presque.
Configurer WordPress pour forcer HTTPS
Les deux champs Adresse web de WordPress et Adresse web du site dans Réglages > Général doivent impérativement commencer par https://. En complément, ajouter la constante suivante dans le fichier wp-config.php force l’administration en HTTPS :
define('FORCE_SSL_ADMIN', true);Utiliser des URL relatives dans le code
Dans les fichiers du thème, privilégier les fonctions WordPress home_url(), get_template_directory_uri() et wp_enqueue_script() plutôt que des chemins absolus écrits en dur. Ces fonctions respectent automatiquement le protocole configuré dans les réglages du site.
Surveiller les mises à jour et les ajouts de contenu
Les mises à jour automatiques de WordPress peuvent modifier des fichiers de thème ou de plugin. Après chaque mise à jour majeure, un passage rapide dans la console DevTools sur quelques pages clés suffit à détecter une éventuelle régression.
Pour les sites gérés par plusieurs contributeurs, une politique éditoriale claire aide à prévenir les erreurs : ne jamais coller d’URL en HTTP dans l’éditeur, toujours utiliser la médiathèque WordPress pour insérer des images (qui génère automatiquement des URL relatives), et vérifier les intégrations tierces avant publication.
La double authentification sur l’administration limite par ailleurs le risque qu’un accès non autorisé introduise du contenu malveillant avec des appels HTTP volontairement insécurisés.
Le versionnement du code avec Git offre un filet de sécurité supplémentaire : chaque modification de fichier est traçable, et un retour en arrière reste possible si une mise à jour introduit des URL en HTTP dans le thème.
Enfin, la minification des fichiers CSS et JS doit être réalisée après la correction des URL, car les fichiers minifiés embarquent parfois des chemins absolus qui échappent au rechercher-remplacer dans la base de données.
À retenir
- Commencer par un inventaire complet des ressources HTTP avec la console DevTools et un crawler comme Screaming Frog
- Effectuer un rechercher-remplacer sérialisé dans la base de données avec WP-CLI ou Better Search Replace (après sauvegarde)
- Ajouter l’en-tête Content-Security-Policy: upgrade-insecure-requests comme filet de sécurité pendant la transition
- Activer HSTS avec preload une fois que toutes les ressources sont confirmées en HTTPS
- Vérifier les scripts tiers (tracking, widgets, polices) qui échappent au remplacement dans la base de données
Questions fréquentes
Comment rétablir le HTTPS et le cadenas sur un site qui affiche « non sécurisé » ?
Le message « non sécurisé » signale la présence de contenu mixte ou l’absence de certificat SSL. Si le certificat est installé, ouvrir la console DevTools (F12) pour identifier chaque ressource chargée en HTTP. Corriger ces URL dans la base de données et dans les fichiers du thème, puis ajouter une redirection 301 de HTTP vers HTTPS dans le fichier .htaccess. Le cadenas réapparaît dès que toutes les ressources de la page sont servies en HTTPS.
Comment enlever l’échec de la connexion sécurisée dans le navigateur ?
L’échec de connexion sécurisée provient généralement d’un certificat SSL expiré, mal configuré ou dont la chaîne de confiance est incomplète. Vérifier la validité du certificat avec l’outil gratuit SSL Labs de Qualys. Si le certificat est valide mais que l’erreur persiste, le problème vient souvent d’un protocole TLS obsolète (TLS 1.0 ou 1.1) désactivé par les navigateurs modernes. Mettre à jour la configuration du serveur pour utiliser TLS 1.2 ou 1.3 résout le problème.
Comment résoudre le problème de certificat SSL sur un site WordPress ?
Vérifier d’abord que le certificat couvre bien le nom de domaine utilisé (avec ou sans www). Ensuite, s’assurer que les réglages WordPress (Adresse web de WordPress et Adresse web du site) utilisent https://. Si le site tourne derrière un proxy ou un CDN, ajouter la ligne $_SERVER['HTTPS'] = 'on'; dans wp-config.php pour que WordPress détecte correctement le protocole. Renouveler le certificat Let’s Encrypt avant son expiration (90 jours) évite les interruptions.
Le contenu mixte affecte-t-il le référencement naturel (SEO) ?
Google utilise le HTTPS comme signal de classement depuis 2014. Un site qui affiche des avertissements de contenu mixte perd le cadenas, ce qui réduit la confiance des visiteurs et peut augmenter le taux de rebond. Si les ressources bloquées incluent des images ou des scripts essentiels, l’expérience utilisateur se dégrade, ce qui a un impact indirect mais réel sur le positionnement. Corriger le contenu mixte contribue à maintenir un signal HTTPS propre pour les moteurs de recherche.
L’en-tête upgrade-insecure-requests suffit-il à corriger définitivement le contenu mixte ?
Non. Cet en-tête demande au navigateur de réécrire les URL HTTP en HTTPS côté client, mais il ne modifie pas le code source du site. Si une ressource tierce n’est pas disponible en HTTPS, la requête échouera silencieusement. De plus, les moteurs de recherche analysent le code source, pas le comportement du navigateur. La correction définitive passe par le remplacement des URL en dur dans la base de données et les fichiers du thème, complété par l’en-tête CSP comme filet de sécurité temporaire.
Comment détecter le contenu mixte sur un site de plus de 100 pages ?
Utiliser un crawler comme Screaming Frog (gratuit jusqu’à 500 URL) ou Sitebulb qui parcourt l’ensemble du site et liste chaque ressource appelée en HTTP. Le rapport indique la page source, le type de ressource et l’URL fautive. Sur WordPress, compléter avec une requête SQL sur la table wp_posts pour identifier les URL HTTP stockées dans le contenu des articles, et un grep récursif dans le dossier wp-content pour les fichiers du thème et des extensions.
Damien Roux est spécialiste de l'hébergement web. Fondateur de web-city.fr, il partage guides pratiques, comparatifs objectifs et outils gratuits pour choisir le bon hébergeur et créer son site WordPress.
À lire aussi
Attaques par force brute sur la page de connexion : les bloquer efficacement
Les attaques par force brute représentent plus de 80 % des tentatives d'intrusion sur les sites WordPress,…
Double authentification sur l’admin : la mesure la plus rentable
Quatre-vingts pour cent des intrusions sur des sites web exploitent un mot de passe volé ou deviné. Le…
Mises à jour automatiques WordPress : lesquelles activer sans risque
Un site WordPress reçoit en moyenne entre 30 et 50 mises à jour par an si l'on additionne le cœur, les…
Sauvegarder un site : fréquence, emplacement et test de restauration
Un site e-commerce qui perd sa base de données un vendredi soir, sans sauvegarde récente : 48 heures de…
Site WordPress piraté : les six étapes dans le bon ordre
Un message d'alerte Google dans la Search Console, des redirections vers des sites de pharmacie en ligne, ou…
Certificat SSL gratuit ou payant : la différence est ailleurs qu’on croit
Un cadenas vert dans la barre d'adresse, une connexion HTTPS, des données chiffrées entre le navigateur et le…
