Prise en charge en cours Lun–Ven · 9h–19h
Signaler un incident
PK.BOT P.03 PK.CFE

Rate limiting : où on le pose et les valeurs qu'on applique

Rate limiting : où on le pose et les valeurs qu'on applique

Un brute force sur wp-login.php envoie des milliers de tentatives par heure depuis une IP ou un bloc d'IPs. Sans rate limiting, chaque tentative arrive jusqu'à PHP, charge WordPress en entier, et consomme des ressources serveur. Avec du rate limiting bien posé, la cinquième tentative échoue et l'IP est bloquée 10 minutes. Voici les endpoints où on le configure et les valeurs qu'on applique chez nos clients.

Définition en une phrase

Le rate limiting est un mécanisme qui limite le nombre de requêtes qu'une source (IP, token, session) peut envoyer vers un endpoint donné sur une période de temps définie, avec une action de blocage ou de challenge quand le seuil est dépassé.

En clair, pour les non-initiés. Imaginez un distributeur automatique qui bloque votre carte après 3 codes PIN erronés. Le rate limiting fait pareil pour votre site : après X tentatives infructueuses sur votre page de connexion dans un laps de temps défini, l'adresse IP est bloquée temporairement. Les humains légitimes font rarement 5 tentatives par minute. Les robots, si.

Pourquoi c'est important pour votre site

Sans rate limiting sur les endpoints sensibles, un attaquant peut :

  • Tester des dizaines de milliers de mots de passe sur votre page de connexion sans aucune friction, jusqu'à trouver le bon.
  • Scraper votre catalogue produit complet en quelques minutes, avec des intervalles entre requêtes trop courts pour être humains.
  • Saturer votre API ou votre checkout avec des requêtes automatisées (card testing, tentatives de coupon).
  • Envoyer des centaines de formulaires de contact ou de spam via vos formulaires publics.

Le rate limiting n'empêche pas une attaque ciblée sophistiquée avec des proxies résidentiels rotatifs. Il arrête les attaques de masse automatisées de bas niveau, qui représentent la grande majorité du bruit malveillant sur un site standard.

Les endpoints où on pose du rate limiting

wp-login.php (WordPress)

L'endpoint de connexion WordPress. Le plus attaqué, le plus critique.

# Règle Cloudflare Rate Limiting
Path : /wp-login.php
Méthode : POST uniquement
Seuil : 5 requêtes POST par minute par IP
Action : Block pendant 10 minutes

On cible POST uniquement pour ne pas bloquer un administrateur qui navigue sur la page de login avant de se connecter (GET). Les tentatives de brute force sont des POST.

/wp-admin/ (WordPress)

L'accès à l'interface d'administration. On combine rate limiting et rule WAF.

# Règle Cloudflare WAF + Rate Limiting
Path : /wp-admin/ (hors /wp-admin/admin-ajax.php)
IPs whitelistées : IPs de l'équipe admin du client
Rate Limit pour les IPs non whitelistées : 10 req/min
Action : Managed Challenge (résolu en arrière-plan pour les humains)

/wp-admin/admin-ajax.php est exclu du rate limiting car il reçoit des requêtes légitimes fréquentes depuis le front-end WordPress (Heartbeat API, plugins AJAX).

/api/ et endpoints REST

Pour les APIs WordPress (/wp-json/) ou les APIs applicatives custom :

# Rate limiting API
Path : /wp-json/ ou /api/
Seuil : 60 requêtes par minute par IP (pour une API interne légère)
Seuil : 30 requêtes par minute par IP (pour des endpoints sensibles type /wp-json/wp/v2/users)
Action : HTTP 429 (Too Many Requests)

L'endpoint /wp-json/wp/v2/users liste les utilisateurs WordPress par défaut. On le rate-limite ou on le désactive si aucune intégration ne le nécessite.

/checkout et pages de paiement (e-commerce)

# Rate limiting checkout
Path contains : /checkout ou /commande ou /order
Seuil : 10 requêtes par 30 secondes par IP
Action : Managed Challenge

Un bot de card testing envoie des dizaines de transactions par minute depuis la même IP ou bloc d'IPs. Le rate limiting le ralentit significativement et augmente le coût de l'attaque.

wp-comments-post.php (WordPress)

Le formulaire de commentaires WordPress, vecteur de spam massif.

# Rate limiting commentaires
Path : /wp-comments-post.php
Méthode : POST
Seuil : 3 requêtes POST par 5 minutes par IP
Action : Block pendant 30 minutes

/xmlrpc.php

Si xmlrpc.php ne peut pas être désactivé (Jetpack actif), on y pose du rate limiting en complément :

Path : /xmlrpc.php
Seuil : 10 requêtes par minute par IP
Action : Block pendant 1 heure

Voir xmlrpc.php pour le contexte complet.

Comment Secushot configure le rate limiting

Dans notre pack PK.BOT et notre protocole P.03 Durcissement, le rate limiting fait partie de la configuration standard. Sur Cloudflare, on utilise les Rate Limiting Rules disponibles dans Security > WAF > Rate limiting rules.

La séquence :

  1. Analyse des logs pour identifier les seuils réalistes. Un site e-commerce avec 500 visites/jour et une page checkout utilisée 30 fois/heure a des seuils différents d'une API interne avec 100 000 appels/heure. On lit les logs avant de poser les chiffres.
  2. Déploiement en mode log d'abord (24 à 48 h sur les endpoints à fort trafic). On valide que les seuils ne bloquent pas du trafic légitime avant de basculer en mode bloquant.
  3. Whitelist des IPs internes : IPs de l'équipe, IPs des outils de monitoring, IPs des services tiers qui appellent l'API.
  4. Ajustement après J+7 sur la base des logs d'événements Cloudflare.

Le piège principal : bloquer Googlebot

Googlebot peut générer un volume de requêtes qui déclenche du rate limiting mal calibré. Symptôme : des pages du site désindexées, une chute de couverture dans Search Console.

Googlebot respecte en principe des intervalles de crawl raisonnables, mais sur des sites avec des sitemaps larges, le volume de crawl peut dépasser des seuils bas.

Solutions :

Whitelister Googlebot via ASN. Cloudflare identifie Googlebot via son ASN (AS15169 Google). On peut l'exclure des règles de rate limiting.

Ne pas appliquer le rate limiting aux User-Agents de crawlers légitimes : Googlebot, Bingbot, Slurp (Yahoo), DuckDuckBot. À combiner avec une vérification via reverse DNS pour confirmer que c'est bien un bot Google légitime et non un bot qui usurpe le User-Agent Googlebot.

Monter les seuils sur les URLs indexées. Les pages publiques crawlées par Google peuvent avoir des seuils plus élevés que les endpoints d'authentification.

Les erreurs qu'on rencontre le plus souvent

1. Rate limiting uniquement sur les IPs, sans tenant par session ou par token

Un attaquant avec un pool de proxies résidentiels rotatifs change d'IP à chaque requête. Le rate limiting par IP seul ne l'arrête pas. On le complète avec du Cloudflare Bot Management qui analyse les comportements au-delà de l'IP.

2. Seuils trop bas sur les endpoints avec du trafic légitime élevé

Un checkout e-commerce lors d'une opération promotionnelle peut recevoir 30 tentatives de paiement par minute depuis la même adresse IP d'une entreprise (acheteurs derrière un NAT partagé). Un seuil à 5 req/min bloquerait des commandes légitimes. On lit les logs et on calibre.

3. Oublier d'exclure /wp-admin/admin-ajax.php du rate limiting sur /wp-admin/

admin-ajax.php reçoit des requêtes fréquentes de l'API WordPress Heartbeat (toutes les 15-60 secondes par session ouverte). Un rate limiting sur /wp-admin/ qui inclut admin-ajax.php bloque les interfaces de l'éditeur et cause des erreurs bizarres pour les administrateurs.

4. Rate limiting sans monitoring des déclenchements

On pose les règles et on oublie de regarder combien de fois elles se déclenchent. Un taux de déclenchement trop élevé sur un endpoint public peut signifier que des utilisateurs légitimes sont bloqués. Un taux nul peut signifier que les seuils sont trop hauts pour être utiles.

Questions fréquentes

Cloudflare Rate Limiting est-il disponible sur le plan Free ? Une version basique est disponible sur tous les plans. Les règles avancées (par session, par token, par en-tête) sont dans les plans payants [à vérifier par l'équipe : limites exactes Free vs Pro avant publication, Cloudflare les fait évoluer régulièrement].

La différence entre rate limiting et CAPTCHA ? Le rate limiting est transparent jusqu'au seuil : aucune friction pour l'utilisateur légitime qui fait moins de X requêtes par minute. Au-delà du seuil, l'IP est bloquée ou challengée. Un CAPTCHA (ou Managed Challenge) s'affiche à chaque session sur certains endpoints. On préfère le rate limiting sur les endpoints de connexion car il ne génère pas de friction pour les utilisateurs normaux.

Le rate limiting protège-t-il contre le credential stuffing ? Partiellement. Il ralentit fortement les attaques depuis une seule IP. Pour les attaques distribuées avec des milliers d'IPs différentes, il faut combiner rate limiting, détection comportementale via Cloudflare Bot Management, et challenge sur les formulaires de connexion. Voir notre page credential stuffing.

Nginx et Apache ont-ils leur propre rate limiting ? Oui. Nginx a limit_req_zone et limit_req. Apache a mod_ratelimit et mod_qos. Ces modules fonctionnent côté serveur, donc après que la requête a consommé de la bande passante et des ressources réseau. Le rate limiting Cloudflare est préférable car il absorbe le trafic avant votre serveur.

Comment savoir si mon rate limiting fonctionne ? Les logs Cloudflare Security Events montrent les requêtes bloquées par règle. En dehors de Cloudflare, les logs Apache/Nginx affichent les HTTP 429 retournés. On vérifie ces métriques à J+7 après déploiement pour confirmer que les règles se déclenchent comme attendu.

Pour aller plus loin

wp-login.php ou votre checkout sous brute force ou card testing ? Notre pack PK.BOT (890 € TTC, livré en 48 h) analyse vos logs, pose le rate limiting adapté et les règles Cloudflare sur vos endpoints sensibles. Rapport chiffré J+7. Briefer le pack PK.BOT

Dernière mise à jour · 22 avril 2026 ← Retour au lexique