Comment corriger une erreur Nginx 403 Forbidden ou « Permission denied » ?

L’erreur Nginx 403 Forbidden signifie que Nginx a compris la requête HTTP, mais refuse l’accès à la ressource demandée. Les causes les plus courantes sont des droits Linux insuffisants sur un fichier ou un répertoire, une directive Nginx restrictive, l’absence de fichier d’index ou un filtrage par un pare-feu applicatif.

La correction ne consiste pas à ouvrir tous les droits avec chmod 777. Un diagnostic fiable commence par les journaux Nginx, puis vérifie le chemin réel du fichier, les permissions de chaque répertoire parent, le compte système utilisé par Nginx et les éventuelles règles externes comme Cloudflare, un WAF ou SELinux.

Que signifie exactement une erreur Nginx 403 Forbidden ?

Une erreur Nginx 403 Forbidden est une réponse HTTP indiquant que le serveur refuse d’autoriser l’accès à une ressource identifiée. La spécification HTTP décrit le statut 403 Forbidden comme un refus de traitement de la requête, même si le serveur la comprend. Le mécanisme central est donc une autorisation refusée, pas une panne générale du serveur.

Nginx est un serveur web et un proxy inverse qui applique des règles avant de servir un fichier, un répertoire, une API ou une application. Le refus peut être produit par Nginx lui-même, par le système Linux, par une couche de sécurité ou par l’application placée derrière le proxy.

Code HTTP	Signification	Premier contrôle utile
401 Unauthorized	Une authentification est demandée ou invalide.	Identifiants, jeton, en-tête Authorization.
403 Forbidden	L’accès est refusé par une règle, un droit ou une politique.	Journaux Nginx, permissions, directives d’accès, WAF.
404 Not Found	La ressource n’est pas trouvée par le serveur.	Chemin, directive root, réécriture d’URL.

Un 403 ne demande pas de « forcer l’accès » : il demande d’identifier quelle couche refuse la requête et selon quelle règle.

Quelles sont les causes les plus fréquentes d’un 403 sous Nginx ?

Les causes d’une erreur Nginx 403 Forbidden se répartissent généralement entre le système de fichiers, la configuration du serveur et les protections situées en amont. Un message tel que permission denied dans le journal d’erreurs oriente d’abord vers les droits Linux ou une politique SELinux.

Les permissions ne concernent pas seulement le fichier final. Le processus Nginx doit aussi pouvoir traverser chaque répertoire situé entre la racine du système et le document demandé. Un fichier index.html lisible ne sera pas servi si le compte Nginx ne possède pas le droit d’exécution sur un répertoire parent tel que /var, /var/www ou le dossier du site.

• Permissions ou propriétaire inadaptés : le compte exécutant Nginx ne peut pas lire le fichier ou traverser un dossier.
• Index absent ou désactivé : Nginx reçoit une demande sur un dossier mais ne trouve aucun fichier prévu par la directive index.
• Directive de refus : une règle deny all;, une liste d’adresses IP ou une règle auth_basic bloque l’accès.
• Racine web erronée : la directive root ou alias pointe vers un chemin inattendu.
• Filtrage extérieur : un CDN, un WAF, une liste de blocage IP ou SELinux refuse la requête avant ou pendant le traitement.

Comment diagnostiquer l’erreur Nginx 403 : les étapes dans le bon ordre

Le diagnostic d’une erreur Nginx 403 Forbidden doit suivre la requête depuis la réponse HTTP jusqu’au fichier visé. Cette méthode évite de modifier des permissions au hasard et permet de distinguer un refus Nginx, un refus Linux et un blocage imposé par une couche externe.

1. Reproduisez la réponse HTTP. Utilisez curl -I https://exemple.fr/chemin pour relever le code, les en-têtes et l’éventuelle signature d’un CDN ou d’un WAF.
2. Consultez le journal d’erreurs. Sur de nombreuses distributions, le fichier se trouve dans /var/log/nginx/error.log. Vérifiez aussi le chemin défini par la directive error_log de votre configuration.
3. Identifiez le bloc serveur réellement chargé. Lancez sudo nginx -T afin d’afficher la configuration effective et de repérer le bon server_name, le root et les règles incluses.
4. Contrôlez le chemin complet. La commande namei -l /chemin/vers/le/fichier affiche les permissions de chaque composant du chemin sur les systèmes qui fournissent cet outil.
5. Testez la configuration avant rechargement. Exécutez sudo nginx -t, puis rechargez Nginx seulement si le test est valide.

Une réponse obtenue avec curl permet aussi de séparer un blocage lié au navigateur d’un refus serveur. Si curl reçoit lui aussi un 403, vider le cache du navigateur ne corrigera pas une règle Nginx ou une permission Linux.

Le journal d’erreurs est le meilleur point de départ : « permission denied », « directory index is forbidden » et « access forbidden by rule » ne désignent pas la même correction.

Corriger les permissions et la configuration Nginx

Les permissions Linux doivent donner à Nginx un accès minimal au contenu publié, sans rendre le site modifiable par tous les comptes du serveur. Les valeurs 644 pour les fichiers et 755 pour les répertoires sont fréquentes dans une racine web publique, mais elles ne remplacent pas la vérification du propriétaire et du groupe.

Le compte de service est souvent www-data sur Debian et Ubuntu, mais ce nom dépend de la distribution et de la directive user définie dans la configuration principale Nginx. La bonne correction consiste à aligner propriétaire, groupe et droits avec le compte réellement utilisé par Nginx.

# Vérifier l’utilisateur configuré pour Nginx
grep -R "^user" /etc/nginx/nginx.conf

# Examiner les droits d’un fichier et de ses répertoires parents
namei -l /var/www/exemple/public/index.html

# Exemple de droits de lecture pour des fichiers publics
find /var/www/exemple/public -type f -exec chmod 644 {} \;

# Exemple de droits de traversée pour les répertoires publics
find /var/www/exemple/public -type d -exec chmod 755 {} \;

Les commandes chmod modifient les droits, tandis que chown modifie le propriétaire et le groupe. Une commande comme sudo chown -R www-data:www-data /var/www/exemple n’est appropriée que si Nginx doit réellement posséder tous les fichiers ; dans un déploiement applicatif, un utilisateur de déploiement peut conserver la propriété avec un groupe lisible par Nginx.

La configuration Nginx doit ensuite correspondre au chemin réellement publié. Vérifiez notamment les directives suivantes dans le bloc server concerné :

• root /var/www/exemple/public; doit viser le répertoire qui contient les fichiers accessibles.
• index index.html index.htm index.php; doit inclure le fichier d’accueil attendu.
• try_files $uri $uri/ =404; peut provoquer un refus de listing sur un dossier sans index, selon le chemin demandé.
• allow et deny doivent être relus dans le bloc http, server et location, car les règles peuvent être héritées.

La documentation officielle de Nginx sur la directive root et celle sur le module index permettent de vérifier la syntaxe applicable à votre version. Testez chaque modification avec nginx -t : un rechargement sans test peut transformer une erreur 403 localisée en indisponibilité plus large.

Pourquoi SELinux, Cloudflare ou un WAF peuvent-ils produire un 403 ?

SELinux, un CDN et un pare-feu applicatif peuvent refuser une requête alors que les permissions Unix paraissent correctes. Un diagnostic utile consiste à vérifier quelle couche a émis la réponse : en-têtes HTTP, page d’erreur personnalisée, journaux Nginx et journaux de sécurité donnent généralement des indices distincts.

Sur une distribution où SELinux est actif, la commande getenforce indique son état et ls -Z affiche le contexte de sécurité d’un fichier. Une erreur d’étiquetage peut empêcher Nginx de lire du contenu placé dans un nouveau chemin ; la correction dépend alors de la politique locale, pas seulement de chmod.

Un CDN comme Cloudflare ou un WAF peut aussi bloquer une adresse IP, une signature de requête, un pays, un chemin sensible ou un débit jugé anormal. Les journaux d’événements du service concerné restent la source à consulter ; désactiver globalement une règle de sécurité sans identifier la requête bloquée augmente le risque sans garantir la résolution.

Le cas WordPress

WordPress fonctionne généralement derrière Nginx sans utiliser directement le fichier .htaccess, qui appartient au fonctionnement d’Apache HTTP Server. Une erreur 403 sur un site WordPress peut venir d’un plugin de sécurité, d’une règle Nginx liée à /wp-admin, d’un mauvais try_files ou d’une restriction sur les fichiers PHP.

Le cas des API et d’OAuth

Une API peut retourner un 403 lorsque le jeton est valide mais ne possède pas le rôle, le périmètre ou la permission attendue. Dans ce cas, les permissions Linux du serveur ne sont pas forcément en cause : contrôlez la réponse de l’application, les revendications du jeton et les règles d’autorisation de l’API.

Nginx, Apache, Caddy ou Traefik : où chercher selon l’architecture ?

Le même code 403 peut provenir de couches différentes selon le serveur utilisé. Nginx applique ses directives de blocs server et location, Apache HTTP Server utilise notamment ses VirtualHosts et peut interpréter .htaccess, tandis que Caddy et Traefik sont souvent employés comme proxys avec une configuration orientée routage.

Composant	Point de contrôle prioritaire	Cas d’usage courant
Nginx	root, location, allow/deny, journaux	Site statique, PHP-FPM, proxy inverse
Apache HTTP Server	VirtualHost, directives Require, fichier .htaccess	Hébergement mutualisé et applications historiques
Caddy	Règles du Caddyfile, routage, authentification	Déploiement simplifié avec HTTPS automatisé
Traefik	Routeurs, middlewares, règles d’accès	Conteneurs et architecture Kubernetes

Une architecture avec Nginx devant une application ou un autre proxy exige de tester chaque maillon. Une requête directe vers l’application interne, limitée à l’environnement d’administration, peut aider à déterminer si le 403 naît dans Nginx ou dans le service situé derrière lui.

Les erreurs fréquentes qui prolongent une erreur 403

Une correction trop large peut masquer le symptôme tout en créant un problème de sécurité. Les pièges ci-dessous reviennent souvent lors du dépannage d’une erreur Nginx 403 Forbidden.

• Appliquer chmod 777 : cette permission autorise l’écriture par tous les utilisateurs locaux. Préférez un propriétaire et un groupe cohérents, avec le droit minimal nécessaire.
• Vérifier seulement le fichier final : un répertoire parent sans droit de traversée suffit à déclencher un refus. Utilisez namei -l sur le chemin complet.
• Modifier le mauvais fichier Nginx : un bloc serveur inactif ou non inclus ne changera rien. Confirmez la configuration effective avec nginx -T.
• Recharger sans test : une erreur de syntaxe peut empêcher le rechargement. Exécutez systématiquement nginx -t.
• Traiter un 403 d’application comme un problème de fichiers : une API, un plugin WordPress ou un WAF peut produire le statut sans rapport avec le disque.

Prévenir le retour d’une erreur Permission denied

La prévention repose sur une configuration reproductible, des droits minimaux et des journaux exploitables. Les chemins de publication, le compte de déploiement et le compte Nginx doivent être définis avant la mise en production, plutôt que corrigés à la main après un refus d’accès.

Documentez le propriétaire attendu de la racine web, appliquez les permissions dans votre processus de déploiement et surveillez les journaux après chaque changement de configuration. La documentation officielle de Nginx détaille les modules et directives à vérifier, tandis que la documentation de votre distribution reste la référence pour SELinux et la gestion des services.

Sources utiles à consulter

• RFC 9110, statut HTTP 403 : définition normative du refus d’accès et distinction avec d’autres réponses HTTP.
• Documentation Nginx du module access : règles allow et deny applicables aux accès IP.
• Documentation Nginx de try_files : comportement de recherche des fichiers et URI.
• Documentation Red Hat Enterprise Linux : référence à consulter pour les politiques SELinux sur les systèmes concernés.

Questions fréquentes sur l’erreur Nginx 403

Pourquoi Nginx affiche-t-il « directory index of … is forbidden » ?

Ce message apparaît souvent lorsqu’une URL vise un répertoire sans fichier d’index reconnu par Nginx. Vérifiez la directive index, la présence du fichier attendu et la valeur de root. L’activation d’un listing de répertoire ne doit pas être une correction automatique, car elle peut exposer des fichiers.

Quelle permission utiliser pour un fichier servi par Nginx ?

La permission 644 est fréquemment utilisée pour des fichiers publics, car elle autorise leur lecture sans ouvrir l’écriture à tous les comptes. Le réglage correct dépend aussi du propriétaire, du groupe et du compte exécutant Nginx. Vérifiez donc le chemin complet avant de modifier les droits.

Pourquoi les permissions 755 ne suffisent-elles pas toujours ?

Une permission 755 sur le dossier final ne suffit pas si un dossier parent bloque la traversée du chemin. SELinux peut également refuser l’accès malgré des permissions Unix correctes. La commande namei -l et les journaux de sécurité aident à distinguer ces deux situations.

Un fichier .htaccess peut-il corriger une erreur 403 sur Nginx ?

Nginx ne lit pas les fichiers .htaccess d’Apache HTTP Server. Sur une installation Nginx seule, les règles doivent être écrites dans les fichiers de configuration Nginx ou dans les fichiers inclus par cette configuration. Un site utilisant Nginx devant Apache peut toutefois avoir des règles à examiner dans les deux couches.