Pour illustrer une page, le plus simple est d’insérer l’adresse d’une image trouvée ailleurs : <img src="https://votre-site.fr/wp-content/uploads/photo.jpg">. L’image s’affiche chez l’autre site, mais c’est votre serveur qui l’envoie, à chacun de ses visiteurs. La documentation d’Apache décrit la pratique comme l’utilisation de votre bande passante pour servir le contenu d’un autre site.
Comment fonctionne le hotlinking
Quand un navigateur charge une image, il indique en général dans l’en-tête HTTP Referer la page qui la contient. MDN précise que cet en-tête peut contenir l’origine, le chemin et les paramètres de la page, selon la politique de référent appliquée. C’est ce qui permet de reconnaître les requêtes venues d’autres sites.
Pourquoi s’en préoccuper
- La bande passante et la charge : une photo reprise sur une page très visitée multiplie les requêtes vers votre hébergement, ce qui pèse sur un forfait limité ou facturé au trafic.
- L’usage de vos visuels : vos créations illustrent un autre site, souvent sans accord ni lien vers vous.
- Un risque d’image : votre fichier peut apparaître sur un site douteux, et toute modification de votre côté s’y reflète.
Comment s’en protéger
La protection repose sur l’en-tête Referer, avec deux limites que rappellent les documentations d’Apache et de Nginx : il est facultatif, donc certains navigateurs ou réglages de confidentialité ne l’envoient pas, et il se falsifie facilement. Il faut donc laisser passer les requêtes sans Referer, et considérer cette protection comme un frein au hotlinking courant, pas comme une mesure de sécurité.
Sur Apache, dans un .htaccess, la documentation propose une règle simple :
SetEnvIf Referer example\.com localreferer
<FilesMatch "\.(jpg|png|gif)$">
Require env localreferer
</FilesMatch>Telle quelle, cette règle refuse aussi les requêtes sans Referer ; la variante avec mod_rewrite de la même page les laisse passer et peut servir une image de remplacement. Sur Nginx, dans le bloc server, le module referer fait le tri :
location ~* \.(jpe?g|png|gif|webp|avif)$ {
valid_referers none blocked server_names *.example.com;
if ($invalid_referer) { return 403; }
}Derrière un CDN, les images servies depuis son cache n’atteignent plus votre serveur : la protection doit être activée dans le CDN lui-même, comme Hotlink Protection chez Cloudflare.
Pour WordPress
Bloquer à l’aveugle peut faire disparaître vos images de Google Images ou des aperçus de liens sur les réseaux sociaux, qui vous apportent des visiteurs. Commencez par observer. WP Masquerade Pro propose pour cela une détection du hotlinking des images : en mode Détecter, il liste les sites qui affichent vos images, avec le nombre de requêtes et la bande passante estimée, sans rien bloquer ; en mode Protéger, il renvoie une image « Image protégée », un pixel transparent ou une erreur 403, tout en laissant passer d’office votre site, les requêtes sans Referer, les moteurs de recherche et les réseaux sociaux. Il écrit ses règles dans le .htaccess sur Apache et LiteSpeed, et fournit le bloc à copier sur Nginx. Comme toute protection de ce type, il ne voit pas les images servies par un CDN, ni les copies d’images hébergées ailleurs.
Les effets sur le référencement des images sont détaillés dans notre article sur le masquage et les vrais effets sur le SEO.