403 n'est ni 401, ni 404
401 Unauthorized signifie que le serveur attend des identifiants, ou que ceux que vous avez envoyés n'ont pas été acceptés. Envoyer des identifiants valides change la réponse.
403 Forbidden signifie que les identifiants ne sont pas en cause. La requête a été comprise et refusée. Se connecter peut ne servir à rien, car ce qui vous a refusé peut très bien ne pas se soucier de qui vous êtes.
Le 404 est parfois utilisé délibérément à la place du 403 pour éviter de confirmer qu'un chemin existe. Si vous obtenez un 403 sur un environnement et un 404 sur un autre pour la même URL, cette différence est un choix de configuration, pas un bug.
Couche 1 — votre origine l'a refusée
Le cas le plus simple. Le fichier existe mais le serveur web ne le sert pas : des permissions de répertoire qui excluent l'utilisateur web, un répertoire sans fichier index et le listing désactivé, une règle .htaccess ou deny nginx, ou une application qui vérifie un rôle et renvoie elle-même un 403.
Comment le reconnaître. La page d'erreur ressemble à votre stack : une page par défaut Apache ou nginx, ou l'écran « vous n'avez pas accès » stylé de votre propre application. Le journal d'accès de votre origine contient la requête avec le statut 403 — c'est le signe révélateur, car cela signifie que la requête a bien atteint l'origine.
Couche 2 — une règle WAF s'est déclenchée
Un pare-feu d'application web inspecte la requête et la bloque quand elle correspond à une signature d'attaque. C'est la couche qui produit les 403 déroutants, parce que la requête paraît parfaitement innocente à la personne qui l'envoie.
Les faux positifs habituels n'ont rien d'exotique : un éditeur CMS qui enregistre un article contenant le mot SELECT dans un exemple de code, un champ de formulaire contenant un extrait de HTML, une description produit avec une apostrophe placée à un endroit particulier. Les jeux de règles livrés avec un WAF sont écrits pour attraper les tentatives d'injection, et du texte humain y ressemble parfois.
Sur cdn.com.tr, le WAF est ModSecurity avec l'OWASP Core Rule Set, et une requête bloquée reçoit une page 403 personnalisée portant un identifiant de référence. Cet identifiant est tout l'intérêt de la chose : c'est l'identifiant de la requête inscrit dans le journal d'audit, qui permet de retrouver exactement quelle règle s'est déclenchée et sur quel champ, au lieu de deviner. La page de journal WAF du panneau liste les événements bloqués avec la catégorie d'attaque, le pays, l'IP et la règle qui s'est déclenchée.
La solution qui vous garde protégé. Exemptez le champ spécifique sur le chemin spécifique — par exemple le corps de l'article sur l'URL de l'éditeur — plutôt que de désactiver une famille de règles partout ou de couper le WAF pour tout le site. Une exclusion étroite ne vous coûte rien ; une exclusion large retire silencieusement la protection de toutes les autres pages.
Couche 3 — un blocage pays ou réseau
Les blocages géographiques et réseau sont appliqués avant que la requête n'atteigne votre application, et ils produisent eux aussi des 403. Si vous avez une liste noire de pays, tout le monde depuis ce pays voit le refus. Si vous bloquez par ASN — un numéro de système autonome, qui couvre tout le réseau d'un opérateur — chaque visiteur chez cet opérateur est refusé, ce qui ratisse bien plus large qu'il n'y paraît.
Le piège à connaître. Les opérateurs mobiles placent des millions d'abonnés ordinaires derrière une poignée d'ASN, et les IP mobiles changent régulièrement. Un visiteur qui allait bien en wifi peut être refusé en données mobiles et décrire cela comme « le site est cassé sur mon téléphone ». Si vos rapports de 403 se concentrent sur les réseaux mobiles, regardez vos blocages avant de regarder votre application.
Ce type de blocage mérite un audit régulier. Une règle ajoutée pendant un incident a tendance à survivre à l'incident.
Couche 4 — protection hotlink et listes d'IP
La protection hotlink refuse les requêtes vers vos images et fichiers quand l'en-tête Referer pointe vers un autre site. Elle fait son travail, mais elle refuse aussi du trafic légitime que vous avez oublié : votre propre domaine de staging, un client mail qui affiche une image, une application qui n'envoie aucun referer du tout. Le symptôme est spécifique et reconnaissable — les pages se chargent, pas les images.
Les listes d'autorisation et de refus d'IP sont la couche la plus brute. Une liste d'autorisation sur un chemin d'administration est un excellent contrôle, jusqu'au jour où l'IP de votre bureau change et que plus personne ne se souvient que la liste existe. Quand un 403 touche exactement une seule personne et personne d'autre, c'est généralement la raison.
Comment trouver la cause, dans l'ordre
Procédez de l'extérieur vers l'intérieur. Cela prend quelques minutes et c'est plus efficace que deviner.
1. Lisez la page d'erreur. Une page personnalisée avec un identifiant de référence signifie une décision en périphérie — une règle WAF, un blocage géo ou ASN. Une page serveur par défaut ou le style de votre propre application signifie que c'est l'origine qui a décidé.
2. S'il y a un identifiant de référence, recherchez-le. Le journal WAF vous donne l'ID de règle, le champ concerné et la valeur qui l'a déclenchée. C'est le chemin le plus rapide du symptôme à la cause, et cela transforme la conversation de « le site me bloque parfois » en « la règle 942100 a matché le corps de l'article ».
3. Vérifiez si c'est seulement vous. Testez depuis un autre réseau ou une connexion mobile. Si c'est seulement vous, regardez les listes d'IP. Si c'est tout le monde depuis un pays, regardez vos blocages géo.
4. Vérifiez si c'est seulement un chemin. Une seule URL qui refuse pendant que le reste du site fonctionne pointe vers les propres règles de l'origine ou une règle WAF liée à ce chemin.
5. Ne regardez l'origine qu'à ce stade. Si la requête n'apparaît jamais dans le journal d'accès de votre origine, elle a été refusée avant d'y arriver, et rien de ce que vous changerez sur l'origine n'y changera quoi que ce soit.
Corriger le problème sans perdre la protection
Le réflexe quand un WAF bloque une requête légitime est de couper le WAF pour ce site. Cela fonctionne, dans le sens où le symptôme disparaît, et cela retire la protection de toutes les autres requêtes auxquelles vous ne pensiez pas.
Une meilleure séquence : reproduisez le blocage, relevez l'ID de règle dans le journal, écrivez une exclusion pour cette règle sur ce champ et ce chemin, puis reproduisez à nouveau pour confirmer que la requête passe et que la règle se déclenche toujours ailleurs. Sur cdn.com.tr, c'est à cela que servent les règles de diffusion et les préréglages de sécurité — l'exclusion vit dans la configuration, se déploie sur chaque périphérie, et reste visible dans l'historique d'activité avec la personne qui l'a faite et les valeurs avant et après.
Si vous ne pouvez pas reproduire le blocage, ne commencez pas à écrire des exclusions. Une exclusion pour une règle qui n'était pas en cause, c'est de la protection retirée pour rien.
FAQ 403 Forbidden
Pourquoi la même URL fonctionne dans un navigateur et pas dans un autre ?
La requête n'est pas identique. Des user agents différents, des cookies différents, et en particulier des réseaux différents — un navigateur en wifi et un en données mobiles partent d'adresses IP différentes. Si le refus suit le réseau plutôt que le navigateur, regardez les blocages IP, pays ou ASN plutôt que votre application.
Mon WAF bloque mon propre éditeur quand j'enregistre un article. Que dois-je changer ?
Trouvez l'ID de règle à partir de l'événement bloqué, puis exemptez cette règle pour le champ que l'éditeur envoie sur l'URL de l'éditeur. N'exemptez pas tout le chemin et ne désactivez pas la famille de règles pour le site : les mêmes règles protègent le reste de vos formulaires, et les tentatives d'injection arrivent par les mêmes champs que le texte légitime.
Un 403 peut-il être mis en cache ?
Oui, et un 403 en cache est une mauvaise surprise, car la cause disparaît alors que le symptôme reste. Les réponses d'erreur devraient généralement être servies avec un TTL court ou ne pas être mises en cache du tout. Si vous avez corrigé la cause et que les visiteurs voient encore le refus, purgez le chemin avant de continuer à déboguer.
L'identifiant de référence sur la page d'erreur — à quoi sert-il ?
C'est l'identifiant de cette requête exacte dans le journal d'audit. Un visiteur peut vous l'envoyer et vous pouvez retrouver quelle règle s'est déclenchée, sur quel champ, avec quelle valeur. Sans lui, un signalement du type « 403 de temps en temps » est presque impossible à investiguer.
Un 403 nuit-il à mon SEO ?
Oui, s'il s'agit d'une page que vous voulez voir indexée, car le robot d'exploration est refusé comme n'importe quel autre client et finira par abandonner l'URL. Le cas à surveiller est un blocage trop large qui attrape les robots des moteurs de recherche — vérifiez que les pages qui comptent pour vous répondent 200 à un robot, pas seulement à votre navigateur.