Le contenu mixte se produit quand une page HTTPS charge des sous-ressources (images, scripts, feuilles de style, polices) via du HTTP non chiffré. Les navigateurs bloquent ou avertissent de cela car une ressource non sécurisée sur une page sécurisée compromet la sécurité de toute la page.
Deux types de contenu mixte
| Type | Exemples | Comportement du navigateur |
|---|---|---|
| Actif (dangereux) | Scripts, iframes, XHR, CSS | Bloqué par tous les navigateurs |
| Passif (affichage) | Images, audio, vidéo | Affiché avec avertissement / cadenas dégradé |
Le contenu mixte actif peut modifier la page (un attaquant man-in-the-middle pourrait injecter du JavaScript malveillant), donc les navigateurs le bloquent complètement. Le contenu mixte passif est moins dangereux mais dégrade quand même l’indicateur de sécurité.
Comment trouver le contenu mixte
DevTools du navigateur
- Ouvrez votre site dans Chrome/Firefox
- Ouvrez DevTools (F12) → onglet Console
- Cherchez des erreurs comme :
Mixed Content: The page at 'https://example.com' was loaded over HTTPS, but requested an insecure resource 'http://example.com/image.jpg'.
Scan en ligne de commande
curl -s https://yourdomain.com | grep -oP 'http://[^"'"'"'> ]+' | sort -uCauses courantes et corrections
URLs http:// codées en dur dans le HTML
<!-- Problème -->
<img src="http://example.com/logo.png">
<!-- Correction : utiliser le protocole relatif ou HTTPS -->
<img src="https://example.com/logo.png">
<img src="//example.com/logo.png">
<img src="/logo.png">Bonne pratique : utilisez des chemins relatifs (/images/logo.png) autant que possible.
Ressources tierces encore en HTTP
<!-- Problème -->
<script src="http://cdn.example.com/library.js"></script>
<!-- Correction -->
<script src="https://cdn.example.com/library.js"></script>Si le tiers ne prend pas en charge HTTPS, trouvez un fournisseur alternatif ou hébergez la ressource vous-même.
Contenu de base de données avec URLs codées en dur
WordPress et d’autres CMS stockent des URLs absolues dans la base de données. Après la migration vers HTTPS :
-- WordPress : mettre à jour les URLs dans les articles
UPDATE wp_posts SET post_content = REPLACE(post_content, 'http://example.com', 'https://example.com');
UPDATE wp_options SET option_value = REPLACE(option_value, 'http://example.com', 'https://example.com');Ou utilisez un plugin comme Better Search Replace.
CSS avec des références HTTP
/* Problème */
background-image: url('http://example.com/bg.jpg');
/* Correction */
background-image: url('https://example.com/bg.jpg');
background-image: url('/images/bg.jpg');Content Security Policy (CSP) — prévenir le contenu mixte futur
Ajoutez un en-tête CSP qui bloque les ressources HTTP :
Nginx :
add_header Content-Security-Policy "upgrade-insecure-requests" always;Apache :
Header always set Content-Security-Policy "upgrade-insecure-requests"upgrade-insecure-requests indique aux navigateurs de mettre à niveau automatiquement les requêtes http:// en https:// — un filet de sécurité pendant que vous corrigez les URLs sources.
Correction systématique : audit complet du site
Pour un nettoyage approfondi, auditez l’ensemble de votre site :
1. Crawler pour les références HTTP
# Scanner tous les fichiers HTML pour les URLs http://
find /var/www/html -name '*.html' -o -name '*.php' | xargs grep -l 'http://' 2>/dev/null
# Scanner les fichiers CSS
find /var/www/html -name '*.css' | xargs grep -l 'http://' 2>/dev/null
# Scanner les fichiers JavaScript
find /var/www/html -name '*.js' | xargs grep -l 'http://' 2>/dev/null2. Corriger les URLs par catégorie
| Source | Méthode de correction |
|---|---|
| Vos propres ressources | Changer en chemins relatifs (/images/logo.png) |
| Ressources CDN | Mettre à jour vers https://cdn.example.com/... |
| Scripts tiers | Mettre à jour l’URL ou trouver une alternative HTTPS |
| CSS en ligne | Rechercher-remplacer http:// → https:// |
| Contenu base de données (WordPress) | wp search-replace 'http://yourdomain.com' 'https://yourdomain.com' |
| Fichiers de template/thème | Modifier directement les fichiers sources |
3. Vérifier avec les DevTools du navigateur
Après les corrections, ouvrez chaque page → DevTools (F12) → onglet Console. Une page propre n’affiche aucun avertissement de contenu mixte. L’icône du cadenas doit être pleine (ni cassée ni avec un triangle d’avertissement).
4. Prévenir le contenu mixte futur
Ajoutez cette balise meta dans le <head> de votre HTML comme filet de sécurité permanent :
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">Ou définissez-le à l’échelle du serveur via la configuration Nginx/Apache (montrée ci-dessus).
Types de contenu qui causent couramment du contenu mixte
| Type de contenu | Où vérifier | Exemple |
|---|---|---|
| Images | <img src="http://..."> | Images uploadées, avatars, logos |
| Scripts | <script src="http://..."> | Analytics, widgets de chat, scripts publicitaires |
| Feuilles de style | <link href="http://..."> | Polices externes, frameworks CSS |
| Polices | @font-face { src: url("http://...") } | Google Fonts (généralement pas de problème), polices personnalisées |
| iframes | <iframe src="http://..."> | Vidéos intégrées, cartes, widgets |
| XHR/Fetch | fetch("http://...") | Appels API en JavaScript |
| Images de fond | background-image: url("http://...") | Arrière-plans CSS |
Questions fréquentes
Le contenu mixte affecte-t-il mon SEO ?
Pas directement. Google crawle en se basant sur le protocole d’URL de la page, pas sur les sous-ressources. Cependant, si le contenu mixte déclenche des avertissements du navigateur ou bloque du contenu visible, l’expérience utilisateur se dégrade — ce qui peut indirectement nuire aux classements via un taux de rebond plus élevé.
Puis-je simplement utiliser upgrade-insecure-requests sans corriger les URLs ?
Cela fonctionne comme solution temporaire, mais corriger les URLs sources est préférable. L’en-tête CSP dépend de la prise en charge du navigateur (tous les navigateurs modernes le supportent, mais certains anciens clients non) et ajoute un en-tête supplémentaire à chaque réponse.
Mon site a des centaines d’URLs HTTP codées en dur. Quelle est la correction la plus rapide ?
Ajoutez l’en-tête CSP upgrade-insecure-requests immédiatement (une ligne de configuration serveur). Ensuite, faites un rechercher-remplacer global dans votre codebase et votre base de données. Utilisez grep -r 'http://' src/ pour trouver les URLs codées en dur dans le code.