Une erreur 403 Forbidden signifie que le serveur a reçu la requête, l’a comprise et a refusé d’y répondre. Contrairement à une 401, se connecter ne résout pas forcément le problème : le serveur indique que ce client, depuis cette adresse, avec ces permissions, n’a pas accès à cette ressource. La cause est presque toujours une règle, pas une panne : permissions de fichiers, fichier index manquant, règle deny dans la configuration du serveur, pare-feu ou protection anti-bots, blocage d’IP ou de pays, ou compte sans le bon rôle. Les propriétaires de site trouvent la règle dans le journal d’erreurs ou dans le journal d’événements du pare-feu ; les visiteurs, eux, ne peuvent guère changer que ce qu’ils envoient.
403, 401 et 404
CodeCe que dit le serveurCe qui aide401 UnauthorizedQui êtes-vous ? Envoyez vos identifiants.Se connecter, ou une clé d’API ou un jeton valide403 ForbiddenJe sais ce que vous voulez, et vous ne l’aurez pas.D’autres permissions, une autre adresse ou une autre requête404 Not FoundIl n’y a rien ici.La bonne adresse
Les serveurs ne suivent pas toujours la théorie. Certains répondent 404 au lieu de 403 pour cacher l’existence d’une page privée, et d’autres répondent 403 pour des fichiers absents : un bucket de stockage privé, par exemple, peut répondre 403 pour un objet qui n’existe pas lorsque le client n’a pas le droit de lister le bucket. La référence des codes de statut HTTP présente les autres codes.
Causes fréquentes
Permissions des fichiers et des dossiers. L’utilisateur du serveur web ne peut pas lire le fichier ou ouvrir le dossier, souvent après un upload ou un déploiement qui a copié les fichiers sous un autre utilisateur.
Pas de fichier index. Une requête vers un dossier sans index.html ni index.php, sur un serveur où le listage des répertoires est désactivé, renvoie une 403. Un déploiement raté qui a laissé le dossier vide produit le même résultat.
Règles de refus. Un deny all dans nginx, un Require all denied dans Apache, ou une règle dans .htaccess qui bloque un chemin, un type de fichier ou un user agent.
Un pare-feu ou une protection anti-bots. Un WAF, la protection anti-bots d’un CDN ou un plugin de sécurité estime que la requête semble automatisée ou malveillante et la bloque, parfois avec une page de challenge.
Blocages d’IP et de pays. L’adresse, le réseau ou le pays du visiteur figure sur une liste de blocage, ou la page est réservée au réseau d’un bureau ou à un VPN.
Droits insuffisants. Le visiteur est connecté, mais son rôle ne lui donne pas accès à la page, ou une clé d’API n’a pas le scope nécessaire pour l’endpoint.
Liens signés expirés ou incorrects. Les liens de téléchargement avec une signature ou une date d’expiration répondent 403 une fois expirés.
Protection contre le hotlinking. Les images ou fichiers demandés depuis un autre site, ou sans le Referer attendu, sont refusés.
Ce que les visiteurs peuvent essayer
Vérifier l’adresse. Un lien qui se termine par un dossier plutôt que par une page, ou un chemin mal saisi, peut tomber sur un dossier que le serveur refuse de lister.
Se connecter, ou se connecter avec le bon compte. Certains sites affichent une 403 aux visiteurs non connectés, ou aux comptes qui n’ont pas l’accès.
Effacer les cookies du site et recharger. Une ancienne session ou un cookie de challenge périmé peut faire que le pare-feu continue de vous refuser.
Changer de réseau. Désactivez un VPN ou un proxy, ou activez-en un, ou essayez les données mobiles. Les adresses partagées et celles des data centers sont bloquées plus souvent que les connexions domestiques.
Désactiver les extensions pour ce site. Certaines extensions de confidentialité modifient les en-têtes d’une façon qui déclenche le pare-feu.
Prévenir le propriétaire du site, en indiquant l’heure et le numéro de référence éventuellement affiché sur la page d’erreur. Ce numéro lui permet de retrouver la règle exacte.
Comment les propriétaires de site trouvent et corrigent le problème
Commencez par identifier qui a répondu. Regardez la page d’erreur et les en-têtes de réponse : un CDN ou un pare-feu se signale généralement, avec une page à son style, un en-tête Server ou un identifiant de requête. Si c’est votre serveur web, son journal d’erreurs indique la raison. Si c’est le CDN ou le WAF, c’est son journal d’événements qui la donne.
Permissions et fichiers index
Sur les hébergements Linux, les dossiers ont généralement besoin de 755 et les fichiers de 644, avec pour propriétaire l’utilisateur sous lequel tourne le serveur web ou PHP. Vérifiez avant de modifier quoi que ce soit, et ne corrigez jamais une 403 avec 777, qui permet à n’importe quel utilisateur du serveur d’écrire dans votre site :
ls -la /var/www/example.com/public
find /var/www/example.com/public -type d -exec chmod 755 {} +
find /var/www/example.com/public -type f -exec chmod 644 {} +
nginx journalise « directory index of … is forbidden » quand un dossier n’a pas de fichier index ; Apache indique qu’il ne trouve pas d’index et que le listage des répertoires est désactivé. Vérifiez que le déploiement a placé les fichiers là où pointe la racine des documents du serveur.
Règles du serveur
nginx journalise « access forbidden by rule » pour un deny, et Apache « client denied by server configuration » pour une règle Require. Cherchez la règle correspondante dans la configuration et dans chaque .htaccess du chemin. Sous WordPress, enregistrer les réglages des permaliens réécrit la partie du cœur dans .htaccess, et les plugins de sécurité y ajoutent leurs propres blocs, ainsi que dans leurs réglages.
Pare-feu, CDN et plugins de sécurité
Retrouvez la requête bloquée dans le journal d’événements par heure, adresse ou identifiant de requête, regardez quelle règle s’est appliquée, puis décidez si la règle est mauvaise ou si la requête était réellement indésirable. Ajoutez des exceptions pour des adresses ou des chemins précis plutôt que de désactiver une règle pour tout le site. Après une modification du pare-feu, testez depuis un réseau extérieur à votre bureau, car votre propre adresse figure peut-être sur une liste blanche.
Pourquoi un moniteur reçoit une 403 alors que votre navigateur non
Un cas fréquent : le site fonctionne pour vous, mais votre outil de surveillance de disponibilité signale une 403. En général, rien n’est cassé. Quelque chose placé devant le site traite la vérification comme un bot, parce que c’en est un :
Protection anti-bots. Les CDN et les WAF soumettent à un challenge les clients qui n’exécutent pas JavaScript ou qui semblent automatisés. Un navigateur résout le challenge ; un moniteur en est incapable, il reçoit donc une 403 ou une page de challenge.
Adresses de data centers. Les moniteurs vérifient depuis des serveurs, et certaines règles bloquent par défaut les réseaux d’hébergement.
Blocages par pays. Un site qui n’autorise que son propre pays bloque un moniteur qui vérifie depuis l’étranger.
Règles de limitation de débit. Certains pare-feu répondent 403 au lieu de 429 lorsqu’un client envoie trop de requêtes.
La solution consiste à mettre le moniteur sur liste blanche, de préférence par ses adresses IP, puisque n’importe qui peut copier un user agent. Ne réglez pas le problème en acceptant la 403 comme « disponible » pour tout le site : un vrai blocage de vos visiteurs passerait alors inaperçu. Si une page doit vraiment rester derrière la protection, surveillez un endpoint de health check situé en dehors. Le guide pour réduire les fausses alertes couvre les autres causes d’alertes qui ne sont pas des pannes.
Les erreurs 403 et Uptimecheck
Un moniteur HTTP(S) de la surveillance de disponibilité d’Uptimecheck considère par défaut les statuts de 200 à 399 comme disponibles : une 403 compte donc comme une panne. Une seconde vérification la confirme avant de vous alerter, et l’incident explique qui a répondu : quand la 403 ou une page de challenge vient de Cloudflare, Sucuri, Imperva, Akamai, DataDome, Vercel, Wordfence ou AWS WAF, il nomme ce service et indique ce qu’il faut y autoriser. Les vérifications de sites web partent de Stockholm, en Suède, avec un user agent qui contient « Uptimecheck ». Comment autoriser Uptimecheck à travers un pare-feu liste nos adresses avec des règles prêtes à l’emploi pour Cloudflare, les plugins de sécurité WordPress et nginx, et pourquoi un moniteur peut être en panne alors que le site fonctionne couvre les autres raisons.
Vous voulez savoir si un site répond tout court ? Le vérificateur Is it down? gratuit considère toute réponse inférieure à 500, 403 comprise, comme disponible : le serveur a répondu, même s’il a refusé.
Distinguez une vérification bloquée d’une vraie panne. Essayez Uptimecheck gratuitement pendant 14 jours, sans carte bancaire.