Résoudre l’erreur « about\:blank#blocked » : images qui ne s’affichent pas sur votre site web

Votre navigateur affiche soudain l’URL about:blank#blocked lorsqu’il tente de charger certaines images ? Cette page vous guide pas à pas pour détecter la cause – qu’elle se situe dans votre navigateur, votre réseau ou la configuration de votre site – et réactiver l’affichage normal de vos médias.

Vue d’ensemble du symptôme

Le problème se manifeste presque toujours de la même manière : sur une page qui devrait afficher une image, vous voyez un carré vide ou une icône « image cassée ». Si vous tentez d’ouvrir l’image dans un nouvel onglet, l’adresse affichée dans la barre d’URL devient instantanément about:blank#blocked. La ressource semble littéralement bloquée avant même d’être chargée.

Pourquoi « about:blank#blocked » apparaît‑il ?

Depuis Chromium 86, la famille de navigateurs basée sur Chromium (Chrome, Edge, Brave, Opera…) remplace l’URL réelle d’une ressource jugée « dangereuse » par le pseudo‑document interne about:blank, assorti du fragment #blocked. Autrement dit, le navigateur refuse de réaliser la requête HTTP/HTTPS et empêche le code JavaScript d’accéder à l’URL originale pour des raisons de sécurité. Les causes possibles sont :

• Content Security Policy (CSP) trop restrictive : la directive img-src n’autorise pas le domaine ou le schéma (HTTP, data URI, blob…).
• Contenu mixte : la page est en HTTPS mais l’image est appelée en HTTP.
• En‑têtes CORS manquants pour une image chargée via JavaScript (fetch, XHR).
• Type MIME erroné : le serveur annonce text/html alors qu’il renvoie un PNG.
• Erreur réseau ou réponse 4xx/5xx, le navigateur masque l’URL au lieu de montrer une erreur classique.
• Bloqueur de contenu : extension, antivirus ou proxy filtrant.

Trois axes de diagnostic

Axe	Vérifications & actions principales
Localiser le problème	Tester le site sur plusieurs navigateurs (Chrome, Firefox, Edge), plusieurs appareils et, si possible, via un réseau différent. Si l’image s’affiche ailleurs, le souci est local ; sinon, il est côté serveur.
Piste « navigateur / extensions »	1. Désactiver toutes les extensions. 2. Vider le cache et les cookies. 3. Réinitialiser le profil ou créer un profil vierge. 4. Réinitialiser les paramètres (Edge : menu … → Paramètres → Réinitialiser les paramètres → Restaurer les paramètres par défaut).
Piste « réseau / système »	1. Réinitialiser la pile TCP/IP et le DNS : ipconfig /flushdns ipconfig /release ipconfig /renew netsh int ip reset netsh winsock reset 2. Vérifier les protocoles TLS activés dans Options Internet. 3. Désactiver tout proxy forcé (Options Internet → Connexions → Paramètres LAN). 4. Effectuer un démarrage minimal (Clean Boot) pour écarter un logiciel tiers.

Inspection rapide dans les DevTools

Avant d’appliquer des correctifs, ouvrez F12 :

• Onglet Network : repérez la ligne correspondant à l’image. Si le statut est (blocked:csp) ou (blocked:mixed-content), la cause est immédiatement connue.
• Onglet Console : les erreurs CSP apparaissent en rouge ; cliquez pour obtenir le détail de la directive violée.
• Onglet Headers pour la requête image : confirmez le chemin, le code HTTP et le Content-Type.

Correctifs côté navigateur

Désactiver les extensions suspectes

Les bloqueurs de traqueurs, d’annonces et les antivirus Web surveillent la balise <img>. Désactivez‑les temporairement, rechargez la page (Ctrl+F5). Si l’image apparaît, ajoutez votre domaine à la liste blanche.

Réinitialiser le profil utilisateur

Un profil corrompu stocke parfois une règle de filtrage persistante. Créez un nouveau profil ou relancez Chrome/Edge avec l’option --user-data-dir=C:\Temp\ProfileTest afin de tester dans un environnement vierge.

Correctifs côté réseau et système

Vérifier le chemin du proxy et du pare‑feu

Un proxy transparent, un filtre parental ou un antimalware réseau peut bloquer les images selon le type MIME ou l’empreinte SHA256. Désactivez‑le ou testez via un partage de connexion 4G : si l’image se charge, le proxy est coupable.

Réinitialiser les protocoles TLS/SSL

Sur certains postes, TLS 1.3 est désactivé manuellement ; de rares serveurs n’acceptent plus TLS 1.0/1.1. Cochez uniquement TLS 1.2 et 1.3 dans Options Internet › Avancé › Sécurité.

Correctifs côté serveur

Vérifier l’existence du fichier et la casse

Sur Linux, /Images/Logo.png diffère de /images/logo.png. Testez :

curl -I https://exemple.com/images/logo.png

Le statut doit être HTTP/1.1 200 OK. Une réponse 404 ou 301 mal configurée provoque parfois un blocage caché.

Servir toutes les ressources en HTTPS

Si votre site a récemment migré vers HTTPS, mettez à jour les liens internes ; Chrome bloque systématiquement les images en HTTP lorsque la page est sécurisée.

Ajuster la Content Security Policy

Lorsque vous activez une CSP, commencez large puis resserrez. Exemple minimaliste autorisant les images depuis le même domaine, les data URI et les sources HTTPS :

<meta http-equiv="Content-Security-Policy"
      content="default-src 'self';
               img-src 'self' https: data:;">

Évitez de copier‑coller une politique trouvée sur Internet ; adaptez chaque directive (script-src, connect-src, etc.) à votre architecture.

Corriger le type MIME

Le serveur doit déclarer :

• Content-Type: image/png pour un PNG
• Content-Type: image/jpeg pour un JPEG
• Content-Type: image/svg+xml pour un SVG

Les CDN et les serveurs mal configurés renvoient parfois text/plain ou application/octet-stream, déclenchant le blocage.

Autoriser l’origine via CORS (chargement JavaScript)

Si l’image est récupérée par fetch() ou Axios, ajoutez :

Access-Control-Allow-Origin: https://votre-site.com

ou * à titre de test (jamais en production).

Étude de cas : CSP trop stricte

Situation initiale : un portfolio contient la directive :

img-src 'self';

Les vignettes proviennent pourtant d’un sous‑domaine CDN  qui est donc bloqué. La console signale :

Refused to load the image 'https://cdn.exemple.com/mini.jpg' because it violates the following Content Security Policy directive: "img-src 'self'".

Solution : élargir la directive :

img-src 'self' https://cdn.exemple.com;

Après redéploiement, les images se chargent sans déclencher about:blank#blocked.

Automatiser les contrôles en ligne de commande

Un script PowerShell de diagnostic express

$url = "https://exemple.com/images/logo.png"
$response = Invoke-WebRequest -Uri $url -Method Head -ErrorAction SilentlyContinue
if ($response.StatusCode -eq 200 -and $response.Headers["Content-Type"] -match "image") {
    "Image valide : $($response.Headers["Content-Type"])"
} else {
    "Problème détecté ($($response.StatusCode)) – Type MIME : $($response.Headers["Content-Type"])"
}

Lancez‑le directement dans une session PowerShell ; il met en évidence un code 404 ou un type MIME erroné en moins d’une seconde.

Check‑list éclair avant de contacter le support

• L’image existe‑t‑elle à l’URL précise ?
• La console DevTools affiche‑t‑elle une erreur CSP, CORS ou Mixed Content ?
• Le serveur renvoie‑t‑il le bon Content-Type ?
• Le problème disparaît‑il en navigation privée sans extensions ?
• Des utilisateurs sur un autre réseau voient‑ils l’image ?

FAQ (Questions fréquentes)

« Puis‑je désactiver complètement la CSP ? »

En théorie oui, mais c’est une mauvaise idée : la CSP protège votre site contre le cross‑site scripting. Ajustez plutôt img-src et default-src avec précision.

« Pourquoi cela n’arrive que sur une seule image ? »

Une minuscule faute de casse dans le chemin ou un seul fichier corrompu suffit. Les navigateurs ne bloquent pas l’ensemble du domaine, seulement la ressource non conforme.

« Firefox ne bloque rien, seul Chrome affiche about:blank#blocked ; qui a raison ? »

Chaque moteur implémente ses propres seuils de sécurité. Chrome applique un niveau plus strict sur le contenu mixte et certains types MIME. Corrigez la cause : votre site deviendra compatible partout.

Conclusion

about:blank#blocked n’est pas une erreur aléatoire ; c’est le signal que le navigateur protège vos visiteurs. En passant systématiquement par les étapes décrites – tests multi‑navigateurs, inspection DevTools, analyse réseau et corrections serveur – vous supprimerez la cause profonde du blocage plutôt que de chercher une solution de contournement fragile. Résultat : des images qui s’affichent instantanément et un site plus sûr.