API Rate Limiting : Throttling, Quota et Protection DDoS

Qu'est-ce que le Rate Limiting ?

Le rate limiting est la limitation du nombre de requêtes qui peuvent être faites dans une période de temps spécifique (seconde, minute, heure).

Objectifs : Prévenir l'abus de l'API, assurer une utilisation équitable, protéger les ressources du serveur, réduire les attaques DDoS.

Quand le rate limit est dépassé : Retourne le code de statut HTTP 429 (Too Many Requests). Spécifie quand réessayer avec le header Retry-After.

Le rate limiting augmente la disponibilité et la fiabilité de l'API. Assure la conformité SLA (Service Level Agreement).

Algorithmes de Rate Limiting

Fixed Window : Compteur maintenu dans une fenêtre de temps fixe (ex. 100 requêtes par minute). Simple mais problème de boundary (spike aux limites de la fenêtre).

Sliding Window Log : Stockez le timestamp de chaque requête. Comptez les requêtes dans les dernières N secondes. Plus précis mais utilise plus de mémoire.

Sliding Window Counter : Hybride de fixed window et sliding window log. Moins de mémoire, résultat plus précis.

Token Bucket : Les tokens sont produits à un taux spécifique. Chaque requête consomme un token. Fournit le support de burst.

Leaky Bucket : Les requêtes sont ajoutées à la queue et traitées à un taux fixe. Fournit le smoothing du trafic.

Stratégies de Rate Limiting

Basé sur l'IP : Limite basée sur l'adresse IP du demandeur. Simple mais les utilisateurs derrière NAT (même IP) ont des problèmes.

Basé sur l'utilisateur : Limite basée sur l'utilisateur authentifié. Plus juste. Identifiez l'utilisateur avec API key ou JWT.

Basé sur l'endpoint : Limite différente pour chaque endpoint. /login (5/min) vs /users (100/min).

Tiered : Limites différentes pour différents types d'utilisateurs. Free (100/min), Pro (1000/min), Enterprise (10000/min).

Global vs par-endpoint : Limite globale (pour toute l'API) + limite par-endpoint. Utilisez les deux ensemble.

Implémentation

Redis : Stockez les compteurs de rate limit dans Redis. Compteur atomique avec les commandes INCR et EXPIRE. Idéal pour le rate limiting distribué.

Middleware : Middleware Express.js (express-rate-limit), Django (django-ratelimit), Spring Boot (Bucket4j).

API Gateway : Rate limiting avec Kong, AWS API Gateway, Cloudflare. Gestion et monitoring centralisés.

Response headers : Retournez les infos de limite avec les headers X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset.

Client SDK : Les bibliothèques client lisent les infos de rate limit et effectuent automatiquement retry et backoff.

Protection DDoS

Le rate limiting seul ne fournit pas de protection DDoS. Les attaques DDoS viennent en volumes dépassant le rate limit.

Cloudflare : Protection DDoS, WAF (Web Application Firewall), gestion des bots. Tier gratuit disponible.

AWS Shield : Protection DDoS pour les services AWS. Standard (gratuit) et Advanced (payant).

Réputation IP : Bloquez les IPs avec une mauvaise réputation. Utilisez des listes de réputation comme Spamhaus, AbuseIPDB.

CAPTCHA : Vérifiez le trafic suspect avec CAPTCHA. reCAPTCHA v3 (invisible) ou hCaptcha.

Geo-blocking : Bloquez le trafic de pays spécifiques (si nécessaire).

Meilleures Pratiques

Graceful degradation : Donnez un message d'erreur clair à l'utilisateur quand le rate limit est dépassé. Spécifiez quand réessayer avec le header Retry-After.

Monitoring : Surveillez les hits de rate limit. Une augmentation anormale peut indiquer une attaque ou un bug.

Whitelist : Mettez en whitelist les IPs de confiance (services internes, APIs de partenaires).

Documentation : Déclarez clairement la politique de rate limit dans la documentation de l'API. Infos de limite, fenêtre et retry.

Tests : Testez le comportement du rate limit avec le load testing. Utilisez k6, Artillery ou JMeter.