Comment bloquer les « mauvais bots » dans vos applications et serveurs web (sans nuire au trafic légitime)

Info Cloud

X (Twitter) Facebook Pinterest LinkedIn Email

Les bots sont partout. Certains sont indispensables (par exemple, Googlebot ou Bingbot indexent votre site pour le référencement), mais d’autres ralentissent, consomment de la bande passante, aspirent du contenu pour entraîner des modèles d’IA ou cherchent des vulnérabilités. Si vous gérez un site web ou une API, il est crucial de faire la différence : permettre ce qui est légitime et bloquer l’abus avant que cela n’atteigne votre serveur.

Voici une fiche pratique — avec exemples et outils — pour un site technologique nécessitant des mesures concrètes sans compromettre le SEO ni l’ergonomie.

1) Identifier le trafic suspect

Avant de bloquer, mesurez :

Logs serveurs (Apache/Nginx) : pics de requêtes répétées sur la même URL, motifs vers /wp-login.php ou /xmlrpc.php, user-agents vides ou falsifiés, rafales nocturnes.
Analytique (GA4/Matomo) : taux de rebond anormaux, sessions de 0 secondes, audiences dans des pays que vous ne visez pas.
Latence et bande passante : si la majorité de votre trafic ne rapporte pas de valeur, il y a du bruit.

Pistes typiques :

Pics sur les points d’accès de connexion, recherches, flux RSS, JSON feeds, ou /wp-json/wp/v2/users (énumération d’utilisateurs).
Téléchargements massifs d’images ou de PDFs.
User-agents imitant Google (“Googlebot/2.1”) avec IP non résolues vers Google.

2) Robots.txt : utile pour les légitimes, insignifiant contre les malveillants

robots.txt ne bloque pas les bots malveillants ; il oriente ceux qui respectent. Toutefois, il peut réduire le crawl superflu :

User-agent: *
Disallow: /wp-admin/
Disallow: /cgi-bin/
Disallow: /search
Allow: /wp-admin/admin-ajax.php

Sitemap: https://votre-domaine.com/sitemap.xml

Important : n’insérez pas de chemins sensibles dans robots.txt s’ils ne sont pas protégés par un autre moyen (authentification, pare-feu). Un bot malveillant pourrait s’en servir comme guide.

3) Bloquages via .htaccess (Apache) ou Nginx : ponctuels, pas la solution miracle

Pour bloquer des IP ou user-agents précis sous Apache :

# .htaccess

  
    Require all granted
    Require not ip 203.0.113.0/24
  


# Blocage par user-agent
BrowserMatchNoCase "curl|python-requests|scrapy|wget" badbot
Order Allow,Deny
Allow from all
Deny from env=badbot

En Nginx :

map $http_user_agent $badbot {
  default 0;
  ~*(curl|python-requests|scrapy|wget) 1;
}

server {
  if ($badbot) { return 403; }
  deny 203.0.113.0/24;
}

Limitations : maintenir manuellement ces listes est coûteux ; les scrapers changent souvent IP et user-agent. Utilisez-les pour des blocages ponctuels, pas comme seul levier.

4) WAF (Web Application Firewall) : filtre en amont de votre application

Un WAF applique des règles standard pour bloquer des motifs malveillants (SQLi, XSS, RFI, bruteforce). Deux approches :

4.1 WAF auto-géré (ModSecurity + OWASP CRS)

ModSecurity (moteur) + OWASP Core Rule Set (règles) : classique et éprouvé.
Vous pouvez ajuster le niveau de paranoïa (PL1 à PL4) et le seuil d’anomalie pour équilibrer sécurité et faux positifs.

Exemple d’une règle spécifique (ModSecurity) pour bloquer les user-agents vides :

SecRule REQUEST_HEADERS:User-Agent "^$" 
"id:1000101,phase:1,deny,status:403,msg:'UA vide bloqué'

4.2 WAF dans le cloud (Cloudflare, autre)

Avantage : filtrage avant que le trafic n’atteigne votre serveur (économie CPU/IO).
Règles paramétrables par expression, réputation IP, pays, ASN, user-agent, présence de scripts, etc.

Exemple (Cloudflare) :
(http.user_agent contains « python-requests ») ou (ip.geoip.country in {« CN » « RU »} and http.request.uri.path eq « /wp-login.php ») → Bloquer

5) Rate limiting et « tests d’humains » sans nuire à l’expérience

Rate limiting : limiter les requêtes par IP/clé API sur les points critiques (connexion, recherche, API).
Défis : utiliser des JavaScript challenges ou des PoW légers (preuves de travail) pour augmenter le coût pour le bot sans trop perturber l’utilisateur.
CAPTCHA accessibles : si une vérification est nécessaire, privilégiez celles centrées sur la vie privée, avec options audio, conformes à WCAG/EAA.

Conseil : appliquez ces défis seulement en cas de risque élevé (nouvelle IP, user-agent suspect, absence de cookies précédents).

6) Traiter avec respect les « bons bots »: vérification et listes blanches

Vérifiez les IP des moteurs de recherche (Googlebot, Bingbot) via reverse DNS et forward-confirmed reverse DNS.
Maintenez une liste blanche pour les intégrations M2M (monitoring, paiements, uptime).
Fournissez des sitemaps à jour et évitez de bloquer les CSS/JS essentiels au rendu.

Résumé pour Googlebot :

Vérifiez le reverse DNS: l’IP doit renvoyer un domaine .googlebot.com ou .google.com.
Vérifiez le forward DNS du domaine obtenu : il doit pointer vers la même IP.

7) Protéger API et endpoints sensibles

Tokens et clés avec scopes et durée d’expiration courte.
Rate limiting spécifique par client (clé/API, OAuth).
Signatures HMAC ou mutual TLS si possible.
CORS stricts et minimum d’autorisations pour méthodes et origines.
Limites de payload et validation approfondie pour éviter l’épuisement de ressources.

8) Mise en place d’un WAF managé (exemple avec RunCloud + ModSecurity)

S’il gère votre hébergement via un panneau intégrant ModSecurity + OWASP CRS (par exemple, RunCloud) :

Dans le dashboard, accédez à Firewall.
Réglez le niveau de paranoïa (commencez en PL1, montez progressivement) et le seuil d’anomalie.
Ajoutez des règles personnalisées pour permettre ou bloquer selon IP, pays, user-agent ou valeurs de cookie.
Activez les notifications et consultez les logs de blocage (ID de règle, endpoint).
Surveillez les faux positifs (ex: recherches internes, formulaires) et définissez des exceptions précises (par route ou paramètre).

Lorsqu’un WAF bloque, la réponse sera un 403 Forbidden. L’objectif : trouver le bon équilibre entre sécurité et expérience utilisateur.

9) Surveillance continue et ajustements

KPIs : requêtes bloquées, faux positifs, consommation en bande passante, CPU/IO.
Alertes : comportements nouveaux (routages inhabituels, tentatives de credential stuffing, scraping intensif).
Revue mensuelle : affinez les règles, mettez à jour la allowlist et surveillez les endpoints critiques.
Tests : réalisez des sinueux tests après chaque modification pour prévenir toute rupture.

10) Exemples prêt-à-copier

Bloquer l’accès à /wp-login.php par pays (Nginx + GeoIP) :

geo $block_country {
  default 0;
  GB 0; US 0; ES 0;  # autorisés
  default 1;          # autres bloqués
}
location = /wp-login.php {
  if ($block_country) { return 403; }
  try_files $uri =404;
  include fastcgi_params;
  fastcgi_pass php-fpm;
}

Apache : bloquer python-requests et curl :

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} "(python-requests|curl)" [NC]
RewriteRule .* - [F]

ModSecurity : limiter xmlrpc.php :

SecRule REQUEST_URI "@streq /xmlrpc.php" 
"id:1000201,phase:1,t:none,deny,status:403,msg:'xmlrpc bloqué'"

Checklist “express”

Logs analysés (user-agents, IP, endpoints suspects).
robots.txt à jour (pas de chemins sensibles).
Rate limiting pour login, recherche, API.
WAF actif (ModSecurity + OWASP CRS ou WAF cloud) et règles sur-mesure.
Allowlist pour bons bots et services M2M.
Définitions de défis just-in-time (JS, PoW, CAPTCHA accessible) en cas de risque élevé.
Protection API (tokens, scopes, CORS, signatures HMAC/mTLS).
Surveillance et alertes ; révision régulière de faux positifs.

Foire aux questions

Puis-je bloquer tous les bots en une fois ?
Ce n’est pas conseillé : vous perdriez du SEO et des services utiles. La stratégie consiste à differencier (WAF + vérification des moteurs + allowlist) et limiter le trafic abusif via rate limiting et challenges pour les risques élevés.

Le fichier robots.txt est-il efficace contre les mauvaises acteurs ?
Non. C’est une simple courtoisie pour les robots légitimes ; les malveillants l’ignorent. Utilisez-le pour orienter les bons, combiné avec WAF et autres limites.

Les blocages IP sont-ils suffisants ?
Ce sont des mesures temporaires : les scrapers changent rapidement d’IP ou d’ASN. Mieux vaut combiner IP, user-agent, pays, rate limiting et réputation.

Comment préserver le SEO ?
Gardez une allowlist de bots vérifiés (Google, Bing), publiez des sitemaps à jour, et ne bloquez pas les CSS/JS nécessaires à l’indexation. Vérifiez aussi l’IP réelle des bots via reverse DNS.

Conclusion

Bloquer les bad bots ne se résout pas par une seule règle magique : il faut des strates. Commencez par analyser, mettez en place un WAF + rate limiting, appliquez des défis de façon ciblée, et sécurisez surtout les API et endpoints coûteux. Avec une surveillance continue et des ajustements réguliers, vous réduirez le bruit sans compromettre le SEO ni l’expérience utilisateur.