Rate limiting proxy: mise en place et test de charge

Publié le 2026-04-13

Pourquoi ajouter du rate limiting

Le durcissement applicatif (token, validation d’entree, limites de payload) reduit deja le risque, mais ne suffit pas a absorber des rafales de requetes.

Un rate limiting au niveau proxy ajoute une protection en amont:

• filtrage avant le backend
• reduction du bruit en logs applicatifs
• limitation des tentatives de bruteforce et des abus de debit

Regles retenues

La politique appliquee est simple et lisible:

1. Priorite sur POST /publish

• 10 requetes par minute et par IP
• burst court a 3 requetes

2. Priorite secondaire sur /notes

• 30 requetes par minute et par IP
• burst a 10 requetes

3. Route API generique en fallback

• priorite inferieure pour laisser passer les routes specialisees en premier

Signalement en cas de depassement

En cas de depassement, la reponse standard est HTTP 429.

Des en-tetes explicites sont exposes:

• Retry-After
• X-RateLimit-Message

Exemple observe apres depassement:

HTTP/2 429
retry-after: 60
x-ratelimit-message: rate limit exceeded, retry later

Test de charge leger execute

Le test est volontairement non destructif:

• requetes avec token invalide sur /publish
• requetes sur /notes sans activation de la fonctionnalite

Resultats constates:

• /publish (20 requetes): 3 x 401, 17 x 429
• /notes (40 requetes): 10 x 404, 30 x 429

Lecture rapide:

• les codes applicatifs restent visibles en dessous du seuil (401, 404)
• le proxy prend bien le relais en surcharge (429)

Point d’attention pratique

L’ordre des middlewares Traefik compte.

Pour conserver les en-tetes explicites sur les 429, l’injection d’en-tetes doit etre placee avant la middleware de rate limiting dans la chaine appliquee au routeur.

Conclusion

Ce durcissement est peu complexe a maintenir et apporte un gain immediat de robustesse operationnelle.

La prochaine etape naturelle consiste a suivre les taux de 429 dans le temps pour ajuster les seuils selon l’usage reel.