Retour au blog
Technologie

Image cassée ailleurs ? Dépannage complet du 403 et du hotlink (2026)

Publié le13 min read
Partager

Vous collez le lien d'une image dans un article de blog, l'aperçu local est nickel. Vous publiez, et les autres voient un cadre d'icône cassée. Ou pire encore — toute la zone de l'image devient une bande blanche, plus rien.

Ce piège, je m'y suis pris plus d'une fois. Une fois en prod, en aidant à migrer les images du forum d'un ami : tout vert en local, mis en ligne, un tiers des vignettes de la page d'accueil cassées. Sur le moment je pensais à un cache pas vidé. Trois jours de debug pour découvrir que le problème n'était pas de mon côté — le site source des images avait activé l'anti-hotlink (hotlink protection) : toute requête ne partant pas de son propre domaine, bloquée.

Vu de l'architecture, « une image qui ne s'affiche pas sur un autre site » mélange en fait trois échecs complètement différents. Pour réparer juste, la première étape est de distinguer lequel vous rencontrez.

Distinguez d'abord : 403, image cassée et 200 blanc sont trois choses différentes

Beaucoup, dès qu'une image manque, disent « image cassée » et tâtonnent au hasard. Or ces trois symptômes ont des causes racines très éloignées, et des chemins de dépannage différents.

Symptôme Code HTTP Cause racine probable Direction de dépannage
Cadre d'icône cassée 403 / 404 anti-hotlink, ou lien lui-même faux vérifier Referer et exactitude de l'URL
Cadre d'icône cassée 200 mais pas une image reçu une page d'erreur HTML, pas le fichier vérifier le Content-Type
Bande blanche (sans icône cassée) 200 CSS qui recouvre, ou CSP qui bloque vérifier Console DevTools et CSP
Icône qui tourne puis disparaît timeout / CORS politique cross-domain ou serveur en timeout vérifier les détails de la requête Network

D'abord le code, puis le Content-Type, en dernier l'écran. Inversez cet ordre et vous tournez en rond.

Le principe : comment fonctionnent le Referer et l'anti-hotlink

Pour comprendre pourquoi l'image d'un autre site se fait bloquer, il faut savoir ce que le navigateur fait en douce au chargement d'une image.

Quand la page A charge l'image du site B via <img src="https://B.com/photo.jpg">, la requête émise par le navigateur embarque un en-tête Referer (oui, ce mot est historiquement mal orthographié, un r en moins, et l'erreur perdure). Cet en-tête dit à B : « cette image est demandée par une page du site A. »

Le principe est le suivant : le serveur ou le CDN de B, à réception, compare le domaine du Referer à une liste blanche. La logique de comparaison ressemble à —

1. Referer vide (ouverture directe, favori) → selon la config, autorisé ou bloqué
2. Domaine du Referer dans la liste blanche → autorisé
3. Domaine du Referer hors liste blanche → 403 Forbidden

Voilà l'anti-hotlink. Son but est simple : ne pas laisser les autres profiter gratuitement de sa bande passante. Vous intégrez une image de B sur votre site ; chaque fois qu'on consulte votre page, la facture de trafic tombe sur B. Forcément, B n'est pas content.

Un détail que beaucoup ignorent : le Referrer-Policy par défaut des navigateurs modernes est strict-origin-when-cross-origin. En requête cross-domain, il n'envoie que le « domaine source » (par exemple https://a.com/), pas le chemin complet. L'anti-hotlink récupère donc votre nom de domaine, suffisant pour comparer à la liste blanche et vous bloquer. Voilà pourquoi l'anti-hotlink vient à bout du hotlink.

Pourquoi votre image casse ailleurs : un arbre de dépannage

Le principe déplié, la cause racine d'une image cassée se ramène à un arbre. Descendez-le simplement.

Branche 1 : le code est-il un 403 ?

Si oui, neuf fois sur dix c'est l'anti-hotlink. B voit que votre Referer n'est pas dans sa liste blanche, refuse tout de suite. Dans ce cas vous ne pouvez pas changer la config de B ; la seule solution est d'arrêter de faire du hotlink sur son image (la bonne méthode plus loin).

Branche 2 : le code est 200, mais l'image casse ?

Ouvrez le contenu brut de cette « image ». Il est probable que vous ayez reçu une page HTML — certains sites ne renvoient pas de 403 mais une page « pas de hotlink svp », avec un code toujours 200. Le navigateur interprète du HTML comme une image, ça casse forcément. Le Content-Type vend la mèche : une vraie image est en image/jpeg, image/png ; une page d'erreur sera en text/html.

Branche 3 : vous avez collé un « lien de page » et non un « lien direct d'image » ?

Le piège numéro un des débutants. https://imgur.com/aBcDeFg est une page, https://i.imgur.com/aBcDeFg.jpg est le fichier image lui-même. Le premier chargé via <img src> renvoie une page HTML entière, pas une image. Un i. et une extension d'écart, et le résultat n'a rien à voir.

Branche 4 : c'est votre Referrer-Policy qui vous plombe vous-même ?

Plus discret. Si votre page a défini Referrer-Policy: no-referrer, le navigateur n'envoie aucun Referer au chargement des images. Or certaines configs anti-hotlink bloquent « tout Referer vide », et vous voilà bloqué par votre propre réglage de confidentialité. En pratique, ce cas apparaît surtout sur les sites très soucieux de vie privée, qui coupent net le meta referrer.

Diagnostic pratique : DevTools et curl, deux gestes qui localisent

La théorie posée, comment vérifie-t-on ? J'utilise systématiquement deux outils, qui localisent 90 % des images cassées en cinq minutes.

Geste 1 : l'onglet Network de DevTools

Ouvrez les outils de développement (F12), passez sur Network, rechargez la page, tapez le nom du fichier image dans le filtre. Cliquez sur cette requête et regardez trois choses :

  • Status : 403, 404 ou 200 ?
  • Le Content-Type des Response Headers : image/* ou text/html ?
  • Le Referer des Request Headers : qu'est-ce qui part vraiment ? vide ou votre domaine ?

Ces trois vus, la cause racine émerge à peu près.

Geste 2 : curl pour contrôler le Referer à la main

DevTools montre le phénomène, mais pour vérifier « est-ce vraiment de l'anti-hotlink », curl est le plus net. Vous injectez n'importe quel Referer et regardez la réaction du serveur :

# Sans Referer du tout (simule l'ouverture directe)
curl -I "https://example.com/photo.jpg"

# Avec un Referer « comme s'il venait du site source lui-même »
curl -I -H "Referer: https://example.com/" "https://example.com/photo.jpg"

# Avec un Referer « venant de votre site externe »
curl -I -H "Referer: https://votre-blog.com/" "https://example.com/photo.jpg"

La lecture est directe. Si le premier et le troisième renvoient 403 mais le deuxième 200 — bingo, anti-hotlink confirmé. Le serveur ne reconnaît que le Referer du site source, bloque tout le reste. Si les trois renvoient 200, l'image cassée n'a rien à voir avec l'anti-hotlink, revenez vérifier votre URL ou votre CSP.

Mon habitude est de lancer les trois d'un coup ; comparer les résultats est bien plus clair que de regarder une seule ligne. Voilà pourquoi curl est plus efficace que cliquer à l'aveugle dans le navigateur.

Comportement anti-hotlink des hébergeurs / CDN courants

Le caractère par défaut varie beaucoup d'un service à l'autre. Voici mes observations après des années de migration d'images ; les réglages réels peuvent changer à tout moment, mais la tendance générale tient.

Type de service Anti-hotlink par défaut Comportement Referer vide Bon pour lien direct externe ?
Nginx / Apache auto-hébergé selon votre config souvent autorisé selon la config
CDN d'entreprise (liste blanche configurable) activable/désactivable configurable ok si bien réglé
Certains hébergeurs gratuits souvent activé souvent bloqué souvent bloqué
Domaines d'images des réseaux sociaux quasi toujours activé quasi toujours bloqué non, laissez tomber
Hébergeur orienté partage souvent désactivé autorisé oui, c'est tout son sens

L'important, c'est la dernière ligne. Les images des réseaux sociaux (ces domaines CDN des plateformes comme Instagram, Facebook), l'URL que vous en copiez est quasi à 100 % non liable en externe, parce que leur modèle économique consiste à vous verrouiller sur la plateforme. Vouloir coller ces images ailleurs, voie sans issue.

Alors qu'un hébergeur orienté « partage » a l'anti-hotlink désactivé par défaut — son sens même est que votre image soit chargée de façon stable par un site externe. Ne confondez surtout pas ces deux catégories.

Le piège du Referrer-Policy : même le navigateur peut se retourner contre vous

J'ai évoqué un cas discret, développons-le, parce que c'est celui qui vous fait douter de votre santé mentale au debug.

Le Referrer-Policy est un en-tête que la page (l'émetteur de la requête) peut définir. Il décide combien d'infos Referer le navigateur envoie. Plusieurs valeurs :

  • no-referrer : n'envoie rien.
  • origin : n'envoie que le domaine source.
  • strict-origin-when-cross-origin : cross-domain, n'envoie que le domaine, rien en cas de rétrogradation vers HTTP (valeur par défaut moderne).
  • unsafe-url : envoie même le chemin complet (déconseillé, fuite de vie privée).

Le paradoxe est là. L'anti-hotlink s'appuie sur le Referer pour juger la source, mais la politique de confidentialité pousse à en envoyer moins, voire pas du tout. Quand un site, par souci de vie privée, met no-referrer, et qu'il charge une image protégée par anti-hotlink « bloquant tout Referer vide », tout casse.

Une de mes pannes en prod venait de là — un site très soucieux de confidentialité avait mis no-referrer partout, résultat toutes les images externes cassées. Sur le moment je croyais l'hébergeur en panne, j'ai cherché longtemps avant de voir que c'était mon propre meta qui étranglait le Referer. Ce piège est difficile à anticiper : comment « renforcer la vie privée » pourrait-il vous nuire ?

La bonne méthode : ne faites pas de hotlink sur l'image des autres

Au bout du dépannage, un fait cruel : tant que l'image n'est pas hébergée par vous, toute « image d'un autre site » peut disparaître à un moment que vous ne contrôlez pas. L'autre change son anti-hotlink, change d'URL, supprime le fichier, ou ferme carrément le site, et votre page casse avec.

Deux voies vraiment stables.

Un, réhébergez l'image dans un endroit que vous contrôlez. N'intégrez pas directement l'URL d'un autre. Téléchargez l'image, uploadez-la sur votre propre espace ou un hébergeur qui autorise le lien externe, et utilisez cette URL stable. Vu de l'architecture, ce geste ramène la disponibilité de votre page du serveur de quelqu'un d'autre vers le vôtre — tant que la source n'est pas sous votre contrôle, chaque ajustement d'anti-hotlink, chaque refonte d'URL, voire chaque mise hors ligne de l'autre se traduit direct par des images cassées sur votre page, sans même un préavis, souvent découvert via un signalement de lecteur. Si vous avez déjà tout un lot de vieux liens éparpillés sur des domaines tiers à migrer d'un coup, j'ai écrit à part un SOP complet de remplacement en masse de liens d'images, qui scanne tout le site avec un script pour tout remplacer d'un coup, bien plus efficace que le faire à la main. Une source que vous contrôlez, voilà une source stable.

Deux, choisissez un hébergeur dont l'anti-hotlink est désactivé par défaut. Beaucoup d'hébergeurs gratuits bloquent le lien externe pour économiser la bande passante, et ça casse dès que vous collez sur un forum ou un blog. Pour du lien externe, prenez un service qui autorise explicitement le lien direct.

C'est un des principes que nous avons posés en faisant lpic.cc : après upload, vous obtenez une URL directe et stable, sans blocage par défaut des sites externes, pour que votre lien collé sur un forum, un blog, Discord s'affiche normalement, sans 403 inexpliqué. Pour une image privée, la protection par mot de passe contrôle qui voit. Envie d'essayer ? Uploadez gratuitement une image, collez le lien sur une autre page, et vous saurez si c'est stable.

Franchement, autant dire les limites honnêtement : l'offre gratuite conserve les images 30 jours, pas d'archivage permanent, et le service vit de revenus publicitaires. Pour de l'archivage long terme ou une grosse banque d'images commerciale, évaluez une offre pro payante, ou auto-hébergez avec sauvegarde. Un outil n'a de sens que dans le bon contexte — ça, je l'ai appris en me prenant le piège.

FAQ

Q : pourquoi le même lien d'image s'ouvre chez moi mais casse collé ailleurs ?

Parce qu'en « ouverture directe » votre Referer est vide ou vient d'une source autorisée, l'anti-hotlink laisse passer. Collé ailleurs, le Referer devient ce domaine externe, hors liste blanche, bloqué en 403. Même URL, Referer différent, résultat opposé.

Q : 403 et image cassée, c'est pareil ?

Non. Le 403 est un refus explicite du serveur (code 403), l'image cassée n'est que la façon dont le navigateur « n'arrive pas à dessiner l'image ». Un 403 cause une image cassée, mais une image cassée peut aussi venir d'une URL fausse, d'un Content-Type faux, d'un CSP qui bloque. Regardez d'abord le code pour savoir laquelle.

Q : mettre Referrer-Policy: no-referrer sur ma page contourne-t-il l'anti-hotlink ?

Parfois oui, parfois pire. Si l'anti-hotlink de l'autre « laisse passer le Referer vide », ne pas envoyer de Referer passe effectivement. Mais s'il « bloque tout Referer vide », tout casse au contraire. Ce truc n'est pas fiable, ne le prenez pas pour la bonne solution.

Q : mon programme (Python / Node) qui récupère l'image se prend aussi un 403, je fais quoi ?

Même logique que le navigateur — votre programme n'a pas mis le bon Referer. Testez d'abord avec curl quel Referer l'autre reconnaît, puis ajoutez le même en-tête dans votre requête HTTP. Attention toutefois : contourner l'anti-hotlink d'autrui pour récupérer ses images peut violer ses conditions d'utilisation, à vous de juger.

Q : comment savoir vite si un hébergeur autorise le lien externe ?

Uploadez une image de test, prenez son lien direct, lancez curl -I -H "Referer: https://google.com/". Renvoie 200, lien externe autorisé ; renvoie 403, anti-hotlink présent, à ne pas coller ailleurs. Vérifié en trente secondes.

References

#hotlink protection#anti-hotlink#403 Forbidden#Referer#Referrer-Policy#CDN#lien direct d'image
H

Rédigé par

Harvey Zhang

Co-fondateur & CTO

Ingénieur backend devenu architecte, il offre une analyse technique approfondie des infrastructures d'hébergement d'images.