Aller au contenu principal
Expert Cybersécurité & IAv9.0
Centres de ressources conformité
Besoin d'un accompagnement expert ?
Devis personnalisé sous 24h — audit, conformité, incident
Outils open source — Gratuits, portables, hors ligne
Caractéristiques communes
100 % hors ligne — aucune donnée transmise
Portables — un seul fichier exécutable
Gratuits — MIT ou GPL v3
Code source ouvert sur GitHub
Checklists Sécurité — Audit & Durcissement
Formats disponibles
📄 PDF 📊 Excel 🌐 Web

11 checklists professionnelles couvrant 2 200+ points de contrôle. Téléchargement gratuit, aucune inscription.

Academy Contact

Rate Limiting

devsecops

Définition

Le Rate Limiting (limitation de débit) est un mécanisme de contrôle qui restreint le nombre de requêtes qu'un client peut effectuer vers une API ou un service dans une fenêtre de temps donnée. C'est un contrôle de sécurité fondamental qui protège contre les attaques par force brute (sur les endpoints d'authentification), les attaques DDoS applicatives, l'extraction massive de données (data harvesting), et les abus des APIs. Dans le contexte DevSecOps, le Rate Limiting est un contrôle de sécurité clé à implémenter systématiquement. Les algorithmes de Rate Limiting les plus courants sont le Token Bucket (les requêtes consomment des tokens; les tokens se rechargent à débit constant; les pics courts sont tolérés dans la limite du bucket), le Leaky Bucket (les requêtes s'écoulent à débit constant, les surplus sont mis en file d'attente ou rejetés), le Fixed Window Counter (comptage de requêtes sur une fenêtre temporelle fixe; susceptible aux attaques exploitant les frontières de fenêtre), et le Sliding Window Counter (hybride combinant précision et performance). Le Rate Limiting peut s'appliquer à différents niveaux de granularité : par adresse IP (protection contre les attaques depuis une source unique), par API key ou token d'authentification (contrôle de l'usage des intégrations), par endpoint spécifique (limites différentes selon la sensibilité : /auth/login beaucoup plus restrictif que /api/products), par tenant ou organisation (dans les architectures multi-tenant), et par combinaison de critères. Les réponses HTTP standardisées pour le Rate Limiting utilisent le code 429 Too Many Requests avec des headers informatifs : Retry-After (secondes avant pouvoir réessayer), X-RateLimit-Limit (limite globale), X-RateLimit-Remaining (requêtes restantes dans la fenêtre), et X-RateLimit-Reset (timestamp de réinitialisation du compteur). Ces headers permettent aux clients bien conçus de s'adapter sans générer de charge inutile. L'implémentation du Rate Limiting peut se faire à différentes couches : dans l'API Gateway (Kong, AWS API Gateway, Nginx), dans des middlewares applicatifs (express-rate-limit pour Node.js, flask-limiter pour Python), ou dans des solutions dédiées (Redis avec rate-limiter-flexible, Envoy avec local/global rate limiting).

Algorithmes de Rate Limiting et leurs cas d'usage

Token Bucket est le plus adapté aux APIs avec des pics légitimes (ex : upload en rafale suivi d'une longue pause). Fixed Window convient aux APIs avec usage régulier et prévisible mais est vulnérable aux attaques de bordure de fenêtre (doubler le débit en 1 seconde chevauchant deux fenêtres). Sliding Window Log est le plus précis mais aussi le plus consommateur en mémoire. En pratique, une combinaison Token Bucket (globale) + Fixed Window (par endpoint sensible) couvre la plupart des cas.

Rate Limiting sur les endpoints critiques

Certains endpoints nécessitent un Rate Limiting particulièrement strict : /auth/login (max 5 tentatives/minute par IP, 20/heure par username), /api/password-reset (max 3/heure par email), /api/register (max 10/heure par IP), /api/otp/verify (max 3 tentatives par OTP), /api/search (max 30/minute pour prévenir l'extraction massive). Ces limites préviennent le brute force, le credential stuffing, l'énumération d'utilisateurs et le scraping de données.

Implémentation et monitoring

Redis est le backend recommandé pour le Rate Limiting distribué (partage de l'état entre instances). Les librairies comme rate-limiter-flexible (Node.js) ou redis-py avec des scripts Lua offrent des implémentations atomic garantissant l'absence de race conditions. Le monitoring des événements 429 par endpoint révèle les attaques en cours ou des problèmes de configuration. Des alertes sur un volume inhabituel de 429 sur /auth/login doivent déclencher une investigation immédiate (credential stuffing potentiel).

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis