Access denied on this server : causes et solutions

Ce que signifie l'erreur

Cette formulation ne fait partie d'aucun standard, ce qui explique pourquoi elle apparaît sous tant de formes différentes. Apache l'affiche depuis une règle de répertoire. ModSecurity et les panneaux de contrôle d'hébergement l'affichent quand une règle se déclenche. Un CDN ou un WAF affiche sa propre version personnalisée avec un numéro de référence. AWS la renvoie sous forme d'un court document XML depuis S3 ou CloudFront. Tous disent la même chose au niveau HTTP : 403, refusé, et aucune invitation à réessayer avec des identifiants.

Ce dernier point la distingue des erreurs avec lesquelles on la confond. Un 401 vous demande de vous authentifier et attend une nouvelle tentative. Un 404 dit que la ressource n'existe pas. Un 403 dit que la ressource existe et que vous ne l'obtiendrez pas, et répéter la requête à l'identique produira la même réponse. Le statut lui-même est couvert dans 403 Forbidden ; ce guide traite de la façon de déterminer quelle couche a dit non.

Commencez par déterminer si c'est vous ou tout le monde, car les solutions n'ont rien en commun. Si un collègue sur un autre réseau charge la page sans problème, c'est vous qui êtes bloqué. Si personne ne peut la charger, le site est mal configuré.

Pourquoi cela arrive

• Votre adresse IP est bloquée. Une règle de pare-feu ou de WAF ajoutée après des échecs de connexion, un scraper sur votre réseau, ou un blocage manuel que personne n'a retiré.
• Limitation de débit. Trop de requêtes dans une courte fenêtre, ce qui est facile à déclencher avec une session de débogage riche en rechargements ou une connexion de bureau partagée.
• Restrictions géographiques. Des sites limités à un pays, ou bloquant une région entière après des abus provenant de celle-ci.
• Une IP partagée ou signalée par sa réputation. Les nœuds de sortie VPN, le NAT des opérateurs mobiles et les plages d'hébergement bon marché sont souvent bloqués en bloc pour ce qu'ont fait d'autres utilisateurs.
• Des règles anti-bot qui lisent votre user agent. Les outils en ligne de commande, les navigateurs headless et les chaînes de user agent inhabituelles sont refusés là où un navigateur normal est autorisé.
• Des cookies périmés ou une session cassée. Un jeton de session expiré peut produire un refus plutôt qu'une redirection vers la page de connexion.
• Une extension de navigateur qui supprime ou ajoute des en-têtes, ou un proxy d'entreprise qui réécrit la requête.
• Des permissions de fichiers et de répertoires. L'utilisateur du serveur web ne peut pas lire le fichier ou traverser un répertoire parent.
• Aucun fichier index, avec le listage désactivé. Une requête de répertoire sans rien à servir et Options -Indexes en vigueur renvoie 403 plutôt qu'une page vide.
• Une règle de refus explicite. Un Require all denied dans la config Apache ou un .htaccess oublié après une fenêtre de maintenance.
• Un faux positif de WAF. ModSecurity et les jeux de règles similaires refusent des requêtes légitimes contenant quelque chose qui ressemble à une tentative d'injection, souvent dans un champ de formulaire ou une chaîne de requête.
• Des permissions de stockage cloud. Une politique de bucket S3 ou un paramètre d'accès à l'origine CloudFront qui ne permet pas la lecture de l'objet.

Si vous êtes le visiteur

1. Confirmez le code de statut plutôt que de faire confiance au texte de la page. curl -s -o /dev/null -w "%{http_code}\n" https://example.com/page vous dit s'il s'agit vraiment d'un 403 ou d'un 401 ou d'un 429 déguisé en message similaire.
2. Ouvrez la page dans une fenêtre privée. Cela élimine les cookies et la plupart des extensions en une seule étape. Un succès à ce moment-là signifie que la solution se trouve sur votre profil, pas sur le site.
3. Effacez les cookies spécifiquement pour ce site plutôt que de tout effacer, puis rechargez.
4. Désactivez le VPN ou le proxy et réessayez. Si cela fonctionne alors, c'est l'adresse du nœud de sortie qui était refusée, et passer à une autre région résout généralement le problème.
5. Essayez un autre réseau, le plus simple étant un téléphone en données mobiles. C'est le moyen le plus rapide de prouver que c'est votre adresse qui est bloquée.
6. Désactivez les extensions une par une, en commençant par les bloqueurs de publicité, les outils de confidentialité et tout ce qui modifie les en-têtes.
7. Vérifiez si le blocage est régional en demandant à quelqu'un dans un autre pays, ou en lisant la page de blocage à la recherche d'une mention de votre localisation.
8. Contactez le site avec le numéro de référence si la page de blocage en affiche un. Les pages de WAF affichent en général un identifiant d'incident qui permet à l'exploitant de retrouver en quelques secondes la règle exacte qui s'est déclenchée.

Si vous êtes le propriétaire du site

1. Lisez d'abord le journal des erreurs. Il nomme directement la cause, et chaque étape suivante n'est que supposition sans lui :

   sudo tail -50 /var/log/apache2/error.log
   sudo tail -50 /var/log/nginx/error.log
   sudo grep -i modsecurity /var/log/apache2/error.log | tail -20

   Apache journalise un problème de permission comme « client denied by server configuration » ou « Permission denied ». nginx journalise « directory index of ... is forbidden » ou « open() ... failed (13: Permission denied) ». Ces trois messages couvrent la plupart des cas.
2. Vérifiez les permissions sur tout le chemin, y compris chaque répertoire parent. Un répertoire que le serveur web ne peut pas traverser refuse tout ce qui se trouve en dessous, aussi correct que paraisse le fichier lui-même :

   namei -l /var/www/html/index.html
   sudo chmod 755 /var/www/html
   sudo chmod 644 /var/www/html/index.html
   sudo chown -R www-data:www-data /var/www/html

3. Cherchez une règle de refus dans le vhost et dans chaque .htaccess sous la racine documentaire. sudo grep -rn "Require\|Deny from" /etc/apache2/sites-enabled /var/www/html les trouve en une seule passe.
4. Ajoutez un fichier index ou activez le listage si la requête cible un répertoire. Servir 403 pour un répertoire nu est le comportement par défaut, pas un dysfonctionnement.
5. Vérifiez SELinux sur les systèmes de la famille Red Hat, où des permissions Unix correctes ne suffisent toujours pas : ls -Z /var/www/html, puis sudo restorecon -Rv /var/www/html.
6. Trouvez la règle WAF qui s'est déclenchée et corrigez soit la requête, soit ajoutez une exception restreinte pour cette règle et ce chemin. Désactiver entièrement le jeu de règles pour faire disparaître l'erreur échange un problème contre un pire.
7. Passez en revue la liste de blocage à la recherche de plages ajoutées pendant un incident. Les blocages temporaires jamais dotés d'une expiration sont une cause fréquente de réclamations des semaines plus tard.
8. Pour S3 ou CloudFront, vérifiez la politique du bucket et la configuration d'accès à l'origine. Le corps XML nomme l'opération refusée, ce qui indique la permission précise à accorder.

Vérifiez depuis l'extérieur

Un refus ciblant une seule adresse ressemble exactement à une panne du site tout entier depuis cette adresse, et vous ne pouvez pas distinguer les deux depuis la machine qui subit le refus. Interrogez le site depuis ailleurs.

Les en-têtes de réponse nomment en général la couche qui a répondu. Regardez Server, et les en-têtes propriétaires tels que CF-Ray ou X-Amz-Cf-Id, qui vous disent si le refus vient de votre origine ou d'une bordure qui ne l'a jamais atteinte :

curl -sS -D - -o /dev/null https://example.com/page
curl -s -o /dev/null -w "%{http_code}\n" -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" https://example.com/page

Si la seconde commande renvoie 200 là où la première renvoyait 403, le blocage porte sur le user agent et rien n'est cassé dans vos permissions. Lancez ensuite la vérification HTTP sur la même URL depuis des points de contrôle dans plusieurs pays à la fois. Un 403 depuis chaque emplacement est un problème de configuration sur le site. Un 403 depuis deux pays et un 200 depuis le reste est une règle géographique ou une liste de blocage régionale, une conclusion que vous ne pouvez pas atteindre avec un seul curl depuis un seul poste de travail.

Repérer un 403 que vous n'aviez pas prévu

Les règles d'accès se cassent de manières qui ne produisent aucune erreur de votre côté. Un jeu de règles WAF se met à jour, un script de renouvellement de certificat réécrit une configuration, un blocage temporaire tombe dans l'oubli, et le site continue de vous renvoyer 200 tout en refusant une partie des vrais visiteurs. Rien dans vos propres journaux n'a l'air alarmant, car un 403 est, du point de vue du serveur, un refus normal et réussi. Une vérification programmée qui lit le code de statut depuis plus de 300 points de contrôle dans 158 villes détecte le jour où une région commence à être refusée, et alerte par e-mail, SMS, appel vocal, Slack, Telegram et bien plus. Les autres guides sont dans la section Résoudre, et le code de statut derrière ce message a sa propre référence dans 403 Forbidden.