Le bouclier anti-saturation

Le contexte

Service public, accès critique pour les citoyens. Un jour, un attaquant a trouvé une endpoint qui était facile à saturer : une page qui requête une certaine base de données avec un N+1 glaring.

Chaque requête = 50 requêtes en base = 500ms de latency. Multiplie par 100 requêtes simultanées et c’est explosion.

Mais voici le twist : l’attaquant ne venait pas de l’extérieur. Il y avait une vulnérabilité XML qui permettait à un utilisateur de faire des requêtes directes à cette endpoint.

Le service n’était protégé par aucun WAF (coûteux). Il y avait juste… du code inefficace.

L’action Leanovia

Phase 1: Audit de résilience applicative

• Scénario : “Et si quelqu’un spamme cette endpoint ?”
• Réponse du code : Crash en moins de 30 secondes
• Pourquoi ? N+1 queries, pas de cache, pas de rate limiting

Phase 2: Optimisation du code

• Rewrite de la requête : 50 queries → 1 query (avec JOIN et GROUP BY)
• Intro de cache distribué (Redis) : Première requête = 500ms, requêtes suiv = 10ms
• Résultat : même endpoint, 100x plus rapide

Phase 3: Rate limiting intelligent

• Rate limite basée sur l’utilisateur (pas sur IP, parce que que IPs d’entreprises)
• Graceful degradation : Au-delà de 100 req/min → retour 429 “Too Many Requests” avec backoff advice
• Isolation des services bruyants (circuit breaker si une dépendance ralentit)

Phase 4: Chaos Engineering

• Simuler une attaque : 10 000 req/s sur l’endpoint
• Avant : Crash
• Après : Graceful degradation, 100% uptime, mais réponses avec latency élevée (acceptable)

Phase 5: Monitoring

• Alerter si le rate limiter se déclenche (signe d’attaque)
• Monitoring de la cache hit ratio (signe d’optimisation efficace)

L’impact

• 100% Disponibilité : Lors d’une tentative réelle de DDoS (découverte par chance), le service n’a pas clignoté
• Résistance charge x10 : Vous pouvez supporter 10x le trafic nominal sans dégradation UX (juste un peu plus lent)
• Pas de WAF coûteux : Au lieu de bloquer les requêtes en amont (WAF = cher), vous les absorbez efficacement

Leçon

La meilleure cyber-résilience n’est pas un pare-feu. C’est du code bien optimisé avec graceful degradation.

Un attaquant peut toujours envoyer plus de requêtes. Mais s’il faut 10 000 requêtes pour impacter le service au lieu de 100, c’est une victoire.