403 Forbidden : causes, corrections et blocages de bots qui trompent les moniteurs

403 face à 401

La RFC 9110 trace la ligne clairement. Un 401 Unauthorized signifie que l'authentification est requise ou que les identifiants fournis n'ont pas été acceptés, et la réponse doit porter un en-tête WWW-Authenticate décrivant comment s'authentifier. Un 403 Forbidden signifie que le serveur refuse d'autoriser la requête, et se réauthentifier n'aidera pas.

La spécification permet aussi à un serveur de répondre 404 plutôt que 403 quand il ne veut pas révéler qu'une ressource existe du tout. C'est pourquoi une URL dont vous savez qu'elle existe peut revenir « introuvable » depuis un serveur durci. Si vous triez un 403, souvenez-vous que le cas inverse existe aussi.

Ce qui produit un 403

• Permissions du système de fichiers. Le processus du serveur web ne peut pas lire le fichier ou traverser le répertoire. Un classique après une copie de fichier manuelle ou une restauration qui a changé le propriétaire.
• Listage de répertoire désactivé. Une requête pour un dossier sans fichier index renvoie 403 sur les serveurs configurés pour refuser les listages. Comportement correct, erreur déroutante.
• Règles d'autorisation applicatives. L'utilisateur est connecté mais n'a pas le rôle, le forfait ou l'appartenance de tenant requis pour cette ressource.
• Listes d'autorisation et de refus par IP. Un chemin d'administration restreint aux adresses du bureau renvoie 403 pour tous les autres, y compris quiconque teste depuis chez lui ou depuis un réseau mobile.
• Règles de pare-feu applicatif (WAF). Un WAF bloque une requête dont l'URL, les en-têtes ou le corps correspondent à une signature. La requête vous paraît souvent entièrement innocente.
• Blocage géographique. Le trafic de certains pays ou régions est refusé en bordure, donc le site va bien depuis un continent et est interdit depuis un autre.
• Protection contre le hotlinking. Une règle qui rejette les requêtes d'images ou de médias dont l'en-tête Referer est absent ou pointe vers un autre domaine. Les requêtes sans référent sont souvent prises par accident.
• Filtrage de bot et de user agent. La requête est bloquée à cause de qui le client prétend être, pas de ce qu'il a demandé. C'est le cas qui piège la surveillance.

Le cas « 403 pour les moniteurs, 200 pour les humains »

C'est la fausse alerte la plus courante en surveillance de disponibilité, et ce n'est pas un bug de surveillance. Le site renvoie réellement 403, simplement pas aux navigateurs.

La gestion des bots sur un CDN ou un WAF note chaque requête selon son user agent, son empreinte TLS, l'ordre de ses en-têtes, la réputation de son IP et le fait qu'elle résolve ou non un défi JavaScript ou interactif. Une vérification HTTP automatisée est, par conception, un client automatisé : elle n'exécute pas de défis JavaScript et s'identifie honnêtement. Elle se fait donc défier ou bloquer pendant que votre navigateur passe sans encombre, et le résultat est un site qui alerte comme étant en panne alors que chaque humain confirme qu'il est en ligne.

Deux signes l'identifient rapidement : le 403 arrive instantanément plutôt qu'après un délai, ce qui exclut une surcharge, et il est constant pour le client automatisé tout en n'étant jamais reproductible dans un navigateur sur le même réseau.

Comment autoriser un service de surveillance

1. Confirmez que le blocage est basé sur l'identité. Répétez la requête comme un client HTTP simple puis avec une chaîne de user agent de navigateur, et comparez :

   curl -sS -o /dev/null -w "%{http_code}\n" https://example.com/
   curl -sS -o /dev/null -w "%{http_code}\n" -A "Mozilla/5.0" https://example.com/

   Si les codes diffèrent, c'est une règle de user agent qui agit.
2. Trouvez la règle qui s'est déclenchée. Les tableaux de bord WAF et CDN journalisent les requêtes bloquées avec l'identifiant de la règle correspondante. C'est plus rapide et plus sûr que de deviner quelle règle assouplir.
3. Autorisez par adresse IP quand vous le pouvez. Les fournisseurs de surveillance publient les adresses que leurs points de contrôle utilisent. Les ajouter comme règle d'exception est précis et n'affaiblit la protection pour personne d'autre.
4. Ou autorisez par user agent. Configurez la vérification pour envoyer un user agent distinctif et ajoutez une règle qui l'exempte. C'est plus facile à maintenir qu'une liste d'IP, mais traitez-le comme une commodité plutôt qu'une limite de sécurité, puisqu'un user agent peut être copié par n'importe qui.
5. Préférez une règle d'exception à la désactivation de la protection. Exemptez le chemin ou le client de surveillance de la règle spécifique, et laissez le reste du jeu de règles en vigueur.
6. Retestez depuis plusieurs régions. Une règle peut être appliquée de façon inégale selon les emplacements de bordure, donc vérifiez la correction depuis plus d'un endroit avant de clore le ticket.

Corriger un 403 qui n'a rien à voir avec les bots

1. Vérifiez si l'URL devrait être publique du tout. La moitié des investigations de 403 se terminent avec la réponse que le blocage est correct.
2. Vérifiez le propriétaire et les permissions du fichier sur le chemin et chaque répertoire parent. Le processus serveur a besoin de la permission d'exécution sur les répertoires, pas seulement de la permission de lecture sur le fichier.
3. Cherchez un fichier index si l'URL est un répertoire, ou activez délibérément un listage si vous en voulez un.
4. Lisez la configuration du serveur à la recherche de règles de refus, de restrictions IP et de vérifications de référent sur ce chemin, puis la couche d'autorisation de l'application.
5. Vérifiez la bordure avant l'origine. Demandez l'origine directement. Un 403 qui disparaît quand vous contournez le CDN est une règle de bordure, pas un problème applicatif.

Voir le blocage depuis l'extérieur de votre propre réseau

Un 403 introduit par une mise à jour de WAF ou un changement de permissions ne ressemble pas à une panne vue de l'intérieur : votre session est authentifiée, votre adresse est autorisée, et les pages que vous vérifiez sont celles qui fonctionnent. Une vérification HTTP programmée fait une assertion sur le code que vous attendez sur les URL qui comptent, depuis l'extérieur de votre réseau, donc une page nouvellement interdite déclenche une alerte immédiatement. Les blocages géographiques et les règles de bordure varient selon la région, donc le nombre de points d'observation compte : HostTracker vérifie depuis plus de 300 points de contrôle dans 158 villes, ce qui transforme « interdit dans certains pays » en une différence visible entre emplacements. Si le refus est temporaire et lié au volume de requêtes plutôt qu'à l'identité, le code sera généralement 429 à la place, couvert dans le guide 429 Too Many Requests, et la famille plus large se trouve dans l'aperçu des 4xx.