Disponibilité et abus
Une application qu'on peut mettre à terre sans effort, ou qui permet à un seul appelant de faire exploser votre facture, pose un problème de sécurité même si aucune donnée ne fuit. Il s'agit ici de limiter ce qu'un seul client peut consommer.
Liste de contrôle
- Limitez le débit de chaque point d'accès, pas seulement celui de la connexion. Plafonnez la fréquence et le nombre d'appels de chaque client (par IP, par compte, par clé). La consommation de ressources non limitée constitue en soi un risque OWASP API. Renvoyez 429 lorsque la limite est dépassée.
- Restreignez davantage les opérations coûteuses. Tout ce qui déclenche un appel de modèle, un e-mail, une conversion de fichier, un rapport ou un parcours de base de données mérite une limite plus stricte, car chaque appel coûte réellement de l'argent ou du CPU.
- Plafonnez la pagination. Un point d'accès de liste doit limiter le nombre d'enregistrements renvoyés par page.
?limit=1000000doit être ramené à une valeur raisonnable, et non honoré. - Plafonnez la taille des envois et des corps de requête avant l'analyse, et limitez le nombre d'envois ou de tâches simultanés qu'un utilisateur peut lancer.
- Définissez des délais d'attente et des limites de concurrence sur les appels sortants comme sur le traitement des requêtes, pour qu'une dépendance lente ne puisse pas épuiser vos workers.
- Placez un CDN ou un WAF devant votre application pour la protection DDoS. Un service comme Cloudflare absorbe les inondations volumétriques et vous permet de limiter le débit et de filtrer par pays à la périphérie, avant que le trafic n'atteigne votre origine. Assurez-vous que l'origine ne peut pas être atteinte directement, en contournant la périphérie (voir infrastructure).
- Échouez de manière sûre et peu coûteuse. Lorsqu'une limite est atteinte ou qu'une dépendance est indisponible, rejetez rapidement avec un statut clair, plutôt que de mettre en file un travail qui s'accumule.
- Surveillez le coût de la mise à l'échelle automatique. Les attaques par épuisement de ressources se manifestent souvent d'abord sur la facture cloud, et non par une panne. Configurez des alertes sur les dépenses et le volume de requêtes inhabituels.
Comment tester
- Envoyez une rafale de requêtes sur chaque point d'accès et vérifiez que vous obtenez des 429.
- Demandez une taille de page énorme et un envoi énorme, et vérifiez que les deux sont plafonnés.
- Vérifiez que l'IP de votre origine ne répond pas directement au trafic de l'application, uniquement via la périphérie.