Sans garde-fou, un script mal écrit ou malveillant pourrait envoyer des milliers de requêtes par seconde à une API et en dégrader le service pour tout le monde. La limitation de débit fixe un plafond, par exemple « 60 requêtes par minute par clé d’API », au-delà duquel le serveur répond une erreur plutôt que de traiter la demande, le temps que la fenêtre se libère.
Où ça se manifeste sur un site WordPress
Deux situations reviennent souvent : une extension qui interroge trop fréquemment une API tierce (météo, taux de change, réseau social) finit par se faire bloquer par le service distant ; et, dans l’autre sens, un site WordPress peut lui-même limiter le débit des tentatives de connexion à wp-login.php ou des appels à son API REST, via des extensions de sécurité, pour se protéger d’attaques par force brute ou de robots trop insistants.
Exemple
HTTP/1.1 429 Too Many Requests
Retry-After: 30Le code 429 et l’en-tête Retry-After indiquent au client combien de secondes attendre avant de réessayer.
Bon à savoir
- Une bonne intégration avec une API tierce lit les en-têtes de quota qu’elle renvoie souvent (comme
X-RateLimit-Remaining) pour ralentir avant d’être bloquée, plutôt que d’attendre l’erreur. - La limitation de débit protège aussi contre certaines attaques par déni de service applicatif, en coupant court aux rafales de requêtes automatisées.
- Un cache bien réglé réduit mécaniquement le nombre d’appels sortants vers une API tierce, ce qui éloigne d’autant le risque d’atteindre un quota.