Limitation de débit (Rate Limiting) et protection de l'API

1. Vue d'ensemble du concept et problématique système

Sans un mécanisme fiable de limitation du débit (rate limiting), tout service web ouvert ou endpoint API est exposé à une menace permanente de collapse technique ou financier :

• Épuisement financier (AI Billing Drain) : Un attaquant ou un script en boucle peut envoyer 100 000 requêtes vers votre route de génération de code ou d'images en 5 minutes, générant une facture de 5 000 $ auprès d'OpenAI ou Anthropic.
• Brute Force et Credential Stuffing : Des botnets automatisés testent des millions de combinaisons de mots de passe sur le formulaire de connexion /api/auth/login, saturant la base de données avec des opérations lourdes de hachage bcrypt/Argon2.
• Effondrement en cascade de la base de données (Denial of Service) : L'appel parallèle massif d'endpoints de recherche non mis en cache épuise le pool de connexions PostgreSQL, paralysant l'application entière.

Le Rate Limiting est le bouclier fondamental de la sécurité système. Il mesure l'intensité du trafic par identifiant (adresse IP, ID de session, clé API) et coupe le trafic excédentaire dès les premières étapes du pipeline, garantissant ainsi la prévisibilité de la charge et la continuité de service pour les utilisateurs légitimes.

2. Taxonomie architecturale et modèle mental

Choix architectural des algorithmes et des niveaux d'implémentation de la limitation du trafic :

┌─────────────────────────────────────────────────────────────┐
│                 TAXONOMIE ALGORITHMIQUE DU RATE LIMITING    │
├─────────────────────────────────────────────────────────────┤
│ 1. Fenêtre fixe : Compteur simple réinitialisé chaque minute│
│    (Vulnérable aux pics de trafic x2 à la limite d'intervalle)│
├─────────────────────────────────────────────────────────────┤
│ 2. Compteur à fenêtre glissante : Fenêtre glissante hybride │
│    Poids = Prev_Count * (1 - Elapsed_Ratio) + Curr_Count    │
│    (Compromis idéal : précision + consommation RAM minimale)│
├─────────────────────────────────────────────────────────────┤
│ 3. Seau de jetons (Token Bucket) : Recharge en jetons à     │
│    vitesse constante                                        │
│    (Autorise les pics légitimes jusqu'à la capacité du seau)│
├─────────────────────────────────────────────────────────────┤
│ 4. Seau percé (Leaky Bucket) : Vitesse d'écoulement         │
│    constante de la file                                     │
│    (Optimal pour lisser les requêtes sortantes vers l'API)  │
└─────────────────────────────────────────────────────────────┘

1. Fenêtre glissante hybride (Sliding Window Counter) :
   • Conserve les compteurs pour l'intervalle de temps courant et précédent. À chaque requête, il calcule une somme pondérée basée sur le pourcentage de temps écoulé dans la fenêtre courante. Cela élimine les anomalies aux frontières des minutes.
2. Hiérarchie des identifiants client (Subject Identification) :
   • Niveau public : Adresse IP (pour les requêtes anonymes et la protection contre les DDoS).
   • Niveau authentifié : User_ID ou Organization_ID (ignore les réseaux NAT/VPN d'entreprise partagés).
   • Niveau Token : Quotas granulaires selon le type de plan acheté (Free, Pro, Enterprise).
3. Backend distribué de stockage d'état (Redis Cluster / Upstash) :
   • Un stockage centralisé en mémoire rapide (In-Memory) qui synchronise les compteurs entre des dizaines d'instances backend en quelques microsecondes.

3. Pipeline technique et mécanique interne

Cycle de vie de la vérification d'une requête via Redis avec un script Lua atomique :

1. Extraction de l'identifiant et de la route : Le Middleware intercepte la requête entrante. Une clé combinée est formée : rate:auth:${req.ip} pour le formulaire de login ou rate:llm:${user.id} pour la route AI.
2. Exécution atomique du script Lua dans Redis : Pour éviter les conditions de course (Race Condition) entre les requêtes parallèles, toute la logique est encapsulée dans un seul script Lua :
   • Lecture du timestamp actuel.
   • Suppression des entrées plus anciennes que la taille de la fenêtre glissante (60 secondes).
   • Calcul du nombre de tokens actifs.
3. Prise de décision :
   • Si la limite n'est pas dépassée : Le compteur est incrémenté de 1 (ou du coût de la requête en tokens), le TTL de la clé est défini, et la requête est transmise au contrôleur.
   • Si la limite est dépassée : Une réponse de refus est générée.
4. Génération des en-têtes HTTP standards : Le serveur retourne les métadonnées au client :

   HTTP/1.1 429 Too Many Requests
   Content-Type: application/json
   Retry-After: 24
   X-RateLimit-Limit: 10
   X-RateLimit-Remaining: 0
   X-RateLimit-Reset: 1718293840
   

5. Télémétrie et alerting : L'événement de dépassement de limite est enregistré dans le système de monitoring ; en cas de pic anormal provenant d'un même sous-réseau, une règle de blocage se déclenche dans le pare-feu.

4. Scénarios d'ingénierie pratiques en production

01. Protection des routes AI génératives coûteuses (Token-Aware Limiting)

La route de génération de code débite les tokens proportionnellement à la complexité de la requête :

• Au lieu d'un simple comptage de requêtes, le rate limiter débite du solde virtuel de l'utilisateur le nombre exact de tokens générés.
• Les utilisateurs du plan gratuit ont une limite de 50 000 tokens par jour. Une fois la limite atteinte, l'API bloque la génération jusqu'au début du jour suivant.

02. Protection du formulaire d'authentification contre le brute force (Credential Defense)

Endpoint /api/auth/sign-in :

• Autorisation de maximum 5 tentatives échouées de mot de passe sur 15 minutes pour une combinaison IP + Email donnée.
• À la 6ème tentative, le système exige la résolution d'un CAPTCHA ou envoie un lien de réinitialisation de mot de passe par email, neutralisant ainsi totalement les tentatives d'attaque par dictionnaire.

03. Lissage du trafic sortant vers les passerelles de paiement tierces

Intégration avec Stripe, où s'applique une limite de 100 requêtes par seconde :

• Le microservice interne utilise une file d'attente avec l'algorithme Leaky Bucket.
• Même si les agents internes de l'entreprise créent simultanément 500 paiements lors du Black Friday, la file d'attente envoie les requêtes selon un flux strictement uniforme (80 req/s), éliminant le risque de blocage du compte Stripe.

5. Pièges, erreurs courantes et sécurité

• Blocage de bureaux entiers via un IP Rate Limiting naïf : Si vous appliquez une limite stricte uniquement par IP aux utilisateurs authentifiés, un employé actif dans un centre d'affaires bloquera le travail de tous ses collègues sortant sur internet via l'adresse NAT partagée de l'entreprise. Après le login, limitez toujours par user_id.
• Race Condition lors de l'utilisation d'opérations séparées GET et INCR : Si vous vérifiez la limite avec GET, puis l'incrémentez via INCR, un attaquant peut envoyer 100 requêtes asynchrones simultanées, et toutes passeront la vérification avant la mise à jour du compteur. Utilisez des scripts atomiques.
• Saturation mémoire de Redis lors du stockage des timestamps : L'utilisation de listes non ordonnées pour stocker le timestamp de chaque requête sans définir de TTL rigide remplit rapidement des gigaoctets de RAM lors d'une attaque massive.
• Ignorance des en-têtes proxy (X-Forwarded-For Spoofing) : Si votre serveur est derrière Cloudflare ou Nginx et que vous lisez l'IP directement depuis le socket, vous obtiendrez l'adresse locale du proxy. D'un autre côté, faire aveuglément confiance à un en-tête X-Forwarded-For non vérifié permet à un attaquant de falsifier n'importe quelle adresse IP.