Protection DDoS pour API et SaaS
Des endpoints qui restent réactifs, des locataires qui restent isolés.
Pourquoi les API sont plus dures à protéger
Protéger les services API est plus délicat que de protéger les sites web traditionnels, car la menace n'est pas seulement une attaque malveillante mais aussi un abus par des utilisateurs légitimes :
- Les CAPTCHA ne s'appliquent pas — les clients API sont des programmes, pas des navigateurs, si bien que les défis de vérification humaine ne se traduisent pas directement.
- Un locataire peut tous nous faire tomber — le script bogué d'un seul client peut épuiser tout le quota de la plateforme.
- Les attaques ressemblent au trafic normal — les appels API à haute fréquence sont le mode de fonctionnement normal de l'activité.
- Les webhooks sont un point faible — les endpoints de callback manquent souvent d'authentification, en faisant une entrée naturelle.
Risques typiques des plateformes API
| Risque | Symptôme | Défense |
|---|---|---|
| Inondation d'endpoint | Un seul endpoint frappé à haute fréquence | Lignes de base de débit par endpoint |
| Abus de quota | Clés valides utilisées bien au-delà de l'intention | Contrôle de quota par clé / par locataire |
| Scraping | Outils automatisés extrayant des données en masse | Empreinte comportementale + analyse de séquence |
| Inondation de webhook | Callbacks spoofés frappant les endpoints internes | Validation de source + vérification de signature |
Comment AwayDDoS protège les API
1. Limitation étagée : global → locataire → endpoint
Nous établissons trois niveaux de contrôle de débit : global pour empêcher la plateforme d'être submergée, par locataire pour empêcher un client de tous nous faire tomber, et par endpoint pour protéger précisément les routes coûteuses. Un déclenchement à un niveau n'affecte pas le trafic normal des autres.
2. Isolation multi-locataire et ordonnancement équitable
Quand le trafic d'un locataire devient anomal, les politiques s'appliquent uniquement à ce locataire — tout le reste est unaffected. C'est critique pour les plateformes SaaS : le problème d'un client ne doit pas devenir la panne de tous.
3. Lignes de base comportementales apprises
Nous modélisons les motifs d'appel normaux par endpoint (QPS, distribution des paramètres, distribution des sources, signature temporelle) et dégradons automatiquement quand le trafic dévie — mise en file, service de cache, ou ré-authentification exigée. Voir CC vs DDoS.
4. Protection des webhooks et callbacks
Les endpoints de callback exigent une validation de source et une vérification de signature obligatoires, avec limitation de débit sur les motifs d'appel anormaux — empêchant les attaquants de pénétrer les systèmes internes via des callbacks spoofés.
Pourquoi les équipes API nous choisissent
- Pas de dépendance aux CAPTCHA — des politiques conçues pour les clients programmatiques qui ne cassent pas l'automatisation API.
- Précision au niveau endpoint — pas une limitation globale brute, mais une protection ciblée des routes qui comptent.
- Connexions longues et support WebSocket — couvrant les motifs API modernes.
- Tarif fixe, jamais en trou noir — une panne API cascade vers chaque client, aussi le trou noir est inacceptable.
Déploiement recommandé
Les activités API combinent typiquement le pilotage DNS (efficace en minutes) avec des tunnels GRE / BGP pour protéger la communication de service interne. Si vos API tournent dans vos propres baies, les tunnels couvrent tous ports et protocoles d'un coup. Voir la comparaison de déploiement.