Une image WordPress qui renvoie une erreur 403 Forbidden, c’est rarement mystérieux. Le serveur a bien compris la requête, mais il refuse de servir le fichier. En clair : “je vois l’image, mais je ne te la donne pas”. Sympa, mais peu pratique.
Dans la majorité des cas, le problème vient des permissions Unix, du propriétaire du fichier, d’une règle serveur, ou d’une protection CDN trop zélée. Voici une méthode propre pour diagnostiquer et corriger le problème sans jouer à la roulette russe avec un chmod 777.
Symptôme : une image WordPress renvoie une erreur 403
Le cas typique : un article WordPress affiche une image cassée. L’URL du fichier semble correcte, l’image existe bien dans wp-content/uploads, mais le navigateur reçoit une erreur 403.
Pour confirmer le code HTTP, utilisez curl depuis votre terminal :
curl -I https://www.example.com/wp-content/uploads/2026/05/image.jpgLangage du code : JavaScript (javascript)Si la réponse contient HTTP/2 403 ou HTTP/1.1 403 Forbidden, le serveur refuse bien l’accès à l’image.
Vérifier les permissions du fichier
Connectez-vous en SSH, puis inspectez le fichier concerné :
ls -l /home/public_html/wp-content/uploads/2026/05/image.jpgUne image avec des permissions comme 600 peut provoquer une erreur 403 si le serveur web n’a pas le droit de la lire. Pour une installation WordPress classique, les fichiers doivent généralement être en 644 ou 640.
Vous pouvez corriger les permissions des fichiers dans le dossier uploads avec :
find /home/public_html/wp-content/uploads -type f -exec chmod 644 {} \;Sur un serveur bien configuré avec un groupe Unix partagé entre votre utilisateur et le serveur web, vous pouvez utiliser une variante plus stricte :
find /home/public_html/wp-content/uploads -type f -exec chmod 640 {} \;Si vous n’êtes pas certain de la configuration du serveur, commencez par 644. C’est le choix le plus compatible sur la plupart des hébergements WordPress.
Vérifier les permissions des dossiers
Les dossiers doivent être traversables par le serveur web. Sans droit d’exécution sur un dossier, le serveur ne peut pas atteindre les fichiers qu’il contient, même si les images elles-mêmes ont les bons droits.
Pour corriger les dossiers dans uploads :
find /home/public_html/wp-content/uploads -type d -exec chmod 755 {} \;Sur une configuration plus verrouillée, avec les bons groupes Unix :
find /home/public_html/wp-content/uploads -type d -exec chmod 750 {} \;La règle simple : f cible les fichiers, d cible les dossiers. Les fichiers ont besoin d’être lisibles. Les dossiers ont besoin d’être traversables.
Vérifier le propriétaire Unix
Les permissions ne suffisent pas toujours. Si les fichiers appartiennent au mauvais utilisateur ou au mauvais groupe, nginx, Apache ou PHP-FPM peuvent refuser l’accès.
Affichez le propriétaire du fichier :
ls -lh /home/public_html/wp-content/uploads/2026/05/image.jpgPour inspecter tout le chemin jusqu’au fichier, utilisez :
namei -l /home/public_html/wp-content/uploads/2026/05/image.jpgCette commande est très utile : elle montre les droits de chaque dossier parent. Une seule permission incorrecte dans le chemin peut suffire à déclencher une 403.
Si nécessaire, corrigez le propriétaire. Adaptez évidemment l’utilisateur et le groupe à votre serveur :
chown -R matt:www-data /home/public_html/wp-content/uploadsSur certains hébergements, le groupe ne sera pas www-data. Il peut s’agir de apache, nginx, du nom du compte système, ou d’un groupe propre à l’hébergeur.
Commande complète pour corriger uploads
Voici la version raisonnable pour une installation WordPress classique :
find /home/public_html/wp-content/uploads -type d -exec chmod 755 {} \;
find /home/public_html/wp-content/uploads -type f -exec chmod 644 {} \;Et voici la variante plus stricte, à utiliser seulement si le serveur web peut lire les fichiers via le groupe Unix :
find /home/public_html/wp-content/uploads -type d -exec chmod 750 {} \;
find /home/public_html/wp-content/uploads -type f -exec chmod 640 {} \;Dans tous les cas, évitez 777. C’est rarement nécessaire, souvent dangereux, et presque toujours le signe qu’on corrige le mauvais problème avec le mauvais marteau.
Tester après correction
Après correction, testez à nouveau l’image :
curl -I https://www.example.com/wp-content/uploads/2026/05/image.jpgLangage du code : JavaScript (javascript)Vous devez obtenir une réponse 200 OK, ou éventuellement 304 Not Modified si l’image est déjà en cache côté navigateur ou CDN.
Si les permissions sont bonnes mais que l’erreur 403 continue
Si les fichiers sont en 644, les dossiers en 755, et que le propriétaire est correct, le problème vient probablement d’une règle serveur ou d’un service intermédiaire.
1. Vérifier Cloudflare Hotlink Protection
Si vous utilisez Cloudflare, vérifiez la protection contre le hotlinking. Elle peut bloquer les images selon le référent HTTP, notamment après une migration, un changement de domaine, ou une configuration CDN un peu trop stricte.
Dans Cloudflare, regardez du côté de Scrape Shield, puis Hotlink Protection. Désactivez temporairement l’option pour tester.
2. Vérifier les règles .htaccess
Sur Apache ou LiteSpeed, une règle .htaccess peut bloquer les images. Cherchez notamment les règles liées au hotlinking, aux extensions de fichiers, aux user agents, ou aux référents.
find /home/public_html -name ".htaccess" -printLangage du code : PHP (php)Ensuite, inspectez les fichiers trouvés :
grep -R "Forbidden\|RewriteCond\|RewriteRule\|jpg\|jpeg\|png\|webp\|avif" /home/public_html/.htaccess /home/public_html/wp-content/.htaccess 2>/dev/nullLangage du code : JavaScript (javascript)3. Vérifier la configuration nginx
Sur nginx, une directive location peut refuser l’accès à certains fichiers. C’est fréquent après l’ajout de règles de sécurité un peu larges.
nginx -T | grep -Ei "deny|location|uploads|jpg|jpeg|png|webp|avif"Langage du code : JavaScript (javascript)Consultez aussi le journal d’erreur nginx :
tail -n 100 /var/log/nginx/error.logLangage du code : JavaScript (javascript)Si vous voyez une erreur du type permission denied, revenez aux droits Unix. Si vous voyez une règle access forbidden by rule, le problème vient plutôt de la configuration nginx.
4. Vérifier les plugins de sécurité WordPress
Certains plugins de sécurité ajoutent des règles dans .htaccess, nginx, ou au niveau PHP. Désactivez temporairement la règle liée au hotlinking, au blocage des répertoires, ou à la protection du dossier uploads.
Ne désactivez pas tout “pour voir” sur un site de production exposé. Testez plutôt une règle à la fois, puis vérifiez avec curl -I.
Cas particulier : images AVIF ou WebP
Si seules les images .webp ou .avif renvoient une erreur, vérifiez les règles serveur par extension. Beaucoup d’anciennes configurations autorisent explicitement jpg, jpeg, png et gif, mais oublient les formats modernes.
Testez chaque format séparément :
curl -I https://www.example.com/wp-content/uploads/2026/05/image.jpg
curl -I https://www.example.com/wp-content/uploads/2026/05/image.webp
curl -I https://www.example.com/wp-content/uploads/2026/05/image.avifLangage du code : JavaScript (javascript)Si les JPEG passent mais pas les WebP ou AVIF, le souci vient probablement d’une règle serveur, d’un CDN, ou d’une configuration MIME incomplète.
Checklist rapide
- Tester l’image avec
curl -I. - Vérifier les permissions du fichier avec
ls -l. - Vérifier tout le chemin avec
namei -l. - Corriger les fichiers en
644ou640. - Corriger les dossiers en
755ou750. - Vérifier le propriétaire Unix avec
chownsi nécessaire. - Contrôler Cloudflare Hotlink Protection.
- Inspecter les règles
.htaccessou nginx. - Tester les formats modernes : WebP et AVIF.
- Purger le cache CDN et le cache WordPress après correction.
Conclusion
Une image WordPress en erreur 403 indique presque toujours un refus d’accès, pas un fichier manquant. Commencez par les permissions et le propriétaire Unix. Ensuite seulement, regardez les règles serveur, Cloudflare, le hotlinking et les plugins de sécurité.
La correction la plus courante reste simple : fichiers en 644, dossiers en 755, propriétaire cohérent, puis purge du cache. Le serveur redeviendra aimable. Enfin, presque.
