Gary Illyes, de Google, a confirmé une observation courante selon laquelle le fichier robots.txt n'a qu'un contrôle limité sur les accès non autorisés par les robots d'exploration. Gary a ensuite présenté un aperçu des contrôles d'accès que tous les référenceurs et propriétaires de sites Web devraient connaître.
Fabrice Canel, de Microsoft Bing, a commenté le message de Gary en affirmant que Bing rencontre des sites Web qui tentent de masquer des zones sensibles de leur site Web avec robots.txt, ce qui a pour effet involontaire d'exposer des URL sensibles aux pirates.
Canel a commenté :
« En effet, nous et d’autres moteurs de recherche rencontrons fréquemment des problèmes avec des sites Web qui exposent directement du contenu privé et tentent de dissimuler le problème de sécurité à l’aide du fichier robots.txt. »
Argument courant à propos de Robots.txt
Il semble qu'à chaque fois que le sujet de Robots.txt est abordé, il y a toujours quelqu'un qui doit souligner qu'il ne peut pas bloquer tous les robots d'exploration.
Gary était d’accord avec ce point :
« robots.txt ne peut pas empêcher l'accès non autorisé au contenu », un argument courant qui apparaît dans les discussions sur robots.txt de nos jours ; oui, j'ai paraphrasé. Cette affirmation est vraie, mais je ne pense pas que quiconque connaissant robots.txt ait prétendu le contraire. »
Il a ensuite approfondi la déconstruction de ce que signifie réellement bloquer les robots d'exploration. Il a présenté le processus de blocage des robots d'exploration comme le choix d'une solution qui contrôle ou cède de manière inhérente le contrôle à un site Web. Il l'a présenté comme une demande d'accès (navigateur ou robot d'exploration) et le serveur répondant de plusieurs manières.
Il a énuméré des exemples de contrôle :
- Un fichier robots.txt (laisse au robot le soin de décider s'il doit ou non explorer).
- Pare-feu (WAF ou pare-feu d'application Web – le pare-feu contrôle l'accès)
- Mot de passe de protection
Voici ses propos :
« Si vous avez besoin d'une autorisation d'accès, vous avez besoin d'un élément qui authentifie le demandeur et contrôle ensuite l'accès. Les pare-feu peuvent effectuer l'authentification en fonction de l'adresse IP, votre serveur Web en fonction des informations d'identification transmises à HTTP Auth ou d'un certificat à son client SSL/TLS, ou votre CMS en fonction d'un nom d'utilisateur et d'un mot de passe, puis d'un cookie 1P.
Il y a toujours une information que le demandeur transmet à un composant réseau qui permettra à ce composant d'identifier le demandeur et de contrôler son accès à une ressource. robots.txt, ou toute autre directive d'hébergement de fichiers, confie la décision d'accéder à une ressource au demandeur, ce qui n'est peut-être pas ce que vous souhaitez. Ces fichiers ressemblent davantage à ces poteaux de contrôle de voie ennuyeux dans les aéroports que tout le monde veut traverser, mais ils ne le font pas.
Il y a une place pour les poteaux, mais il y a aussi une place pour les portes anti-explosion et les iris au-dessus de votre Porte des étoiles.
TL;DR : ne considérez pas robots.txt (ou d'autres directives d'hébergement de fichiers) comme une forme d'autorisation d'accès, utilisez les outils appropriés pour cela car il y en a beaucoup.
Utilisez les outils appropriés pour contrôler les robots
Il existe de nombreuses façons de bloquer les scrapers, les robots de piratage, les robots d'exploration de recherche, les visites des agents utilisateurs IA et les robots d'exploration de recherche. Outre le blocage des robots d'exploration de recherche, un pare-feu d'un certain type est une bonne solution car il peut bloquer par comportement (comme la vitesse d'exploration), l'adresse IP, l'agent utilisateur et le pays, entre autres. Les solutions typiques peuvent être au niveau du serveur avec quelque chose comme Fail2Ban, basées sur le cloud comme Cloudflare WAF, ou comme un plugin de sécurité WordPress comme Wordfence.
Lisez le post de Gary Illyes sur LinkedIn :
robots.txt ne peut pas empêcher l'accès non autorisé au contenu
