Rate Limiting et Throttling

1.1 Objectif du Document

Ce document décrit la stratégie complète de Rate Limiting et Throttling mise en place pour la plateforme REWAPP. Il détaille les mécanismes de protection contre les abus, les attaques par déni de service et la surcharge des systèmes, tout en garantissant une expérience utilisateur optimale pour les clients légitimes.

1.2 Définitions et Terminologie

1.3 Documents de Référence

• 6.1 Document de Sécurité
• 6.2 Architecture de Sécurité
• 6.2.1 Authentification et Autorisation
• 6.2.2 Protection des Données (CSRF/XSS)
• 4.3 Architecture Backend API
• 4.5 Stack Technique Détaillé

2.1 Objectifs de Sécurité

La stratégie de Rate Limiting de REWAPP vise à :

• Protéger l'infrastructure contre les attaques DDoS et les abus
• Garantir une disponibilité de 99.9% du service
• Assurer une répartition équitable des ressources entre utilisateurs
• Prévenir les attaques par force brute sur l'authentification
• Protéger les endpoints sensibles (transactions, QR codes)
• Maintenir des temps de réponse API < 200ms

2.2 Principes Fondamentaux

2.3 Architecture Globale

La protection Rate Limiting s'applique à trois niveaux :

3.1 Rate Limiting par Utilisateur

Chaque utilisateur authentifié dispose d'un quota de requêtes basé sur son identifiant unique (user_id extrait du JWT).

3.2 Rate Limiting par IP

Pour les requêtes non authentifiées ou en complément du rate limiting utilisateur.

3.3 Rate Limiting par Endpoint

Certains endpoints critiques ont des limites spécifiques, plus restrictives que les limites globales.

3.4 Rate Limiting Global

Protection de l'infrastructure globale contre les pics de charge.

4.1 Limites par Plateforme

4.2 Limites par Type d'Endpoint

4.3 Configuration par Environnement

4.4 Burst Allowance

Le mécanisme de Burst permet des pics temporaires au-delà de la limite normale pour accommoder les comportements légitimes (ouverture d'app, rafraîchissement de page).

5.1 Mécanismes de Détection

Le throttling adaptatif analyse le comportement en temps réel pour identifier les patterns anormaux :

5.2 Niveaux de Réponse

5.3 Algorithmes Utilisés

6.1 Stack Technique

6.2 Architecture Kong API Gateway

Configuration Kong Rate Limiting Plugin :

6.3 Compteurs Redis

Structure des clés Redis :

rate:user:{user_id}:minute → Compteur par minute utilisateur
rate:ip:{ip_hash}:minute → Compteur par minute IP
rate:endpoint:{path_hash}:{user_id}:minute → Compteur endpoint spécifique
rate:global:second → Compteur global par seconde
penalty:{user_id}:level → Niveau de pénalité actuel
blacklist:ip:{ip_hash} → IP blacklistée

Script Lua pour atomicité :

-- Incrémentation atomique avec TTL
local current = redis.call('INCR', KEYS[1])
if current == 1 then
    redis.call('EXPIRE', KEYS[1], ARGV[1])
end
return current

6.4 Headers HTTP de Réponse

Headers standards retournés sur chaque réponse API :

Exemple de réponse avec headers :

HTTP/1.1 200 OK
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 87
X-RateLimit-Reset: 1732800060
Content-Type: application/json

7.1 Réponses HTTP Standards

Code 429 - Too Many Requests

{
  "statusCode": 429,
  "error": "Too Many Requests",
  "message": "Vous avez dépassé le nombre de requêtes autorisées. Veuillez réessayer dans 30 secondes.",
  "retryAfter": 30,
  "limit": 100,
  "remaining": 0,
  "resetAt": "2025-11-24T15:00:00Z"
}

Code 503 - Service Unavailable (Surcharge globale)

{
  "statusCode": 503,
  "error": "Service Temporarily Unavailable",
  "message": "Le service est temporairement surchargé. Veuillez réessayer dans quelques instants.",
  "retryAfter": 60
}

7.2 Système de Pénalités

Les dépassements répétés entraînent des pénalités progressives :

7.3 Whitelist et Exceptions

Procédure d'ajout whitelist

1. 1

   Demande via ticket support

2. 2

   Validation équipe sécurité

3. 3

   Ajout dans Kong + Redis

4. 4

   Monitoring renforcé 7 jours

5. 5

   Validation définitive

8.1 API d'Authentification

8.2 Génération QR Code

8.3 Scan QR Code (Partenaires)

Le Dashboard Partenaire a des besoins spécifiques pour le scan QR en situation de rush.

8.4 Transactions Bancaires

9.1 Métriques Collectées

9.2 Dashboards de Supervision

9.3 Alertes Automatiques

10.1 Couches de Protection

10.2 AWS Shield et WAF

AWS WAF Rules

10.3 Réponse aux Incidents

Procédure d'escalade DDoS :

11.1 Ajustement des Seuils

Les seuils peuvent être ajustés selon les besoins business ou la croissance.

Procédure de modification

1. 1

   Création ticket avec justification

2. 2

   Analyse impact par équipe tech

3. 3

   Validation équipe sécurité

4. 4

   Déploiement staging + tests 24h

5. 5

   Déploiement production (off-peak)

6. 6

   Monitoring renforcé 7 jours

11.2 Gestion des Incidents

11.3 Communication Utilisateur

Messages utilisateur en cas de rate limit :

12.1 Récapitulatif

La stratégie de Rate Limiting et Throttling de REWAPP assure :

• Protection multicouche : AWS WAF/Shield + Kong + Application
• Limites adaptées : 100 req/min utilisateur, 1000 req/min IP
• Flexibilité : Burst allowance, whitelist, configuration par environnement
• Transparence : Headers HTTP informatifs pour les développeurs
• Résilience : Fallback en cas de panne Redis
• Monitoring : Dashboards temps réel et alertes automatiques
• Conformité : Protection des endpoints sensibles (auth, transactions)

12.2 Points Clés

12.3 Références

Documents complémentaires :

• 6.1 Document de Sécurité
• 6.2 Architecture de Sécurité
• 4.3 Architecture Backend API
• 4.5 Stack Technique Détaillé
• 10.3 Procédures de Monitoring et Alerting