HTTP 429 Too Many Requests : signification et solutions

Ce que signifie cette erreur et comment la reconnaître

• Un navigateur, un client API, un outil de monitoring ou un checker reçoit 429 Too Many Requests.
• La réponse peut affecter une seule URL, route API, méthode HTTP, adresse IP, compte ou client, plutôt que l’ensemble du site.
• Les requêtes peuvent recommencer à fonctionner après un délai, ce qui est cohérent avec une limitation de débit temporaire.
• La réponse peut inclure Retry-After ou d’autres en-têtes liés à la limitation de débit.
• Le DNS peut résoudre le nom et TLS peut aboutir, car la requête a atteint un endpoint parlant HTTP ; ces vérifications ne prouvent pas que la requête est autorisée au niveau applicatif.
• Des clients ou réseaux différents peuvent recevoir des résultats différents lorsque la limite est définie pour une IP, une identité, un token ou une session.

Causes principales, classées par probabilité

1. Une limite de fréquence des requêtes a été dépassée. L’application, l’API gateway ou le serveur web peut limiter les requêtes par adresse IP, compte, session, clé API, route ou autre identité du client.
2. Un proxy, un CDN ou un WAF a appliqué sa propre politique. Un intermédiaire peut renvoyer 429 avant que la requête n’atteigne le serveur d’origine.
3. Un trafic automatisé envoie des requêtes trop rapidement. Des crawlers, vérifications de monitoring, scripts, nouvelles tentatives ou workers parallèles peuvent déclencher une limite, même lorsque chaque requête semble valide.
4. Un client réessaie sans temporisation progressive. Des nouvelles tentatives répétées après des échecs peuvent maintenir le client dans la fenêtre de limitation ou intensifier la charge.
5. Une configuration ou un déploiement a modifié le seuil effectif. Une règle récente, une modification du routage, une intégration d’authentification ou une politique de proxy peut avoir changé les requêtes comptabilisées ou limitées.
6. La limite est intentionnelle, mais le workflow du client est incompatible avec celle-ci. Par exemple, un traitement par lots peut nécessiter un cadencement, la réutilisation des connexions ou un quota de requêtes approuvé plutôt que de nouvelles tentatives immédiates répétées.

Comment corriger le problème

Pour les visiteurs et les consommateurs d’API

1. Arrêtez les actualisations rapides, les requêtes parallèles et les nouvelles tentatives automatiques pendant le diagnostic.
2. Vérifiez les en-têtes de réponse à la recherche de Retry-After. S’il est présent, attendez le délai ou l’heure indiquée avant de réessayer.
3. Réessayez exactement la même URL ou le même endpoint API avec la même méthode après le délai. Ne changez pas de méthode et ne faites pas varier les requêtes à répétition dans le seul but de contourner la limite.
4. Si vous contrôlez le client, utilisez un nombre limité de nouvelles tentatives avec backoff exponentiel et jitter, et respectez le quota de requêtes documenté par le service. Évitez de réessayer les requêtes qui ne peuvent pas être répétées sans risque, sauf si l’API définit leur comportement en cas de nouvelle tentative.
5. Vérifiez si le problème affecte un seul client, compte, clé API, réseau ou endpoint. Un résultat différent avec un autre client ne permet pas, à lui seul, d’identifier la cause.
6. Si le 429 persiste, contactez le propriétaire du site ou de l’API en fournissant l’endpoint, la méthode, l’horodatage, les en-têtes de réponse et une description de la fréquence des requêtes. Supprimez les cookies, valeurs d’autorisation et secrets API de tout élément partagé.

Pour les propriétaires de sites et les développeurs

1. Reproduisez la réponse avec le test autorisé le plus ciblé, correspondant à la méthode, à l’URL, à l’identité du client et à la fréquence de requêtes concernés. Notez le statut, l’horodatage et les en-têtes de réponse pertinents.
2. Identifiez la couche qui génère la réponse. Vérifiez les détails de réponse du CDN ou du WAF, les journaux du reverse proxy, du serveur web et de l’application, dans l’ordre correspondant à votre architecture. Ne supposez pas que le serveur d’origine a généré la réponse.
3. Recherchez dans les journaux concernés le même horodatage, la même route, le même identifiant client et la même décision de limitation. Déterminez ce qui est comptabilisé et quelle fenêtre ou politique de limitation a été appliquée.
4. Comparez la requête affectée à une requête normale. Vérifiez la méthode HTTP, le contexte d’authentification, l’identité source, la route, le chemin de mise en cache et les modifications récentes de déploiement ou de configuration.
5. Si la limite est intentionnelle, améliorez les indications destinées au client : renvoyez une valeur Retry-After exacte lorsque cela est approprié, documentez les quotas et permettez aux clients d’utiliser un backoff contrôlé plutôt que des boucles de nouvelles tentatives rapprochées.
6. Si la limite est incorrecte, appliquez la correction autorisée la plus ciblée sur la couche qui a généré la réponse. Validez son effet sur la route concernée sans affaiblir les protections de sécurité ou contre les abus qui ne sont pas liées.
7. Testez à nouveau la même requête avec la même fréquence, puis testez des routes voisines et des identités client représentatives. Vérifiez que les limites intentionnelles fonctionnent toujours et que la réponse ne bloque plus le trafic légitime.

Prévention et vérification du correctif

• Définissez et documentez les quotas de requêtes, la portée des limites et le comportement en cas de nouvelle tentative pour les API et les clients automatisés.
• Renvoyez des informations utiles sur la limitation, notamment Retry-After lorsque cela est approprié et pris en charge par la conception du service.
• Implémentez un backoff exponentiel limité avec jitter dans les clients, plutôt que des nouvelles tentatives immédiates répétées.
• Surveillez les taux de 429 par route, identité client, réseau et déploiement afin de distinguer les augmentations généralisées des abus isolés ou des clients défaillants.
• Conservez les paramètres de limitation du CDN, du WAF, du proxy, du serveur et de l’application sous gestion de versions, et examinez les modifications avant leur mise en production.
• Testez les méthodes API importantes et les routes publiques après les déploiements, notamment le comportement attendu lorsqu’un seuil est atteint.
• Conservez suffisamment de journaux assainis sur les requêtes et les décisions de politique pour relier une réponse 429 au composant qui l’a générée.

Questions fréquentes