Aller au contenu principal
Expert Cybersécurité & IAv9.0
Centres de ressources conformité
Besoin d'un accompagnement expert ?
Devis personnalisé sous 24h — audit, conformité, incident
Checklists Sécurité — Audit & Durcissement
Formats disponibles
📄 PDF 📊 Excel 🌐 Web

11 checklists professionnelles couvrant 2 200+ points de contrôle. Téléchargement gratuit, aucune inscription.

API4 Unrestricted Resource Consumption

devsecops

Définition

API4 Unrestricted Resource Consumption (anciennement Lack of Resources & Rate Limiting) est le quatrième risque de l'OWASP API Security Top 10, couvrant l'absence de limitations sur la consommation de ressources par les clients d'une API. Sans ces limites, une API est vulnérable aux attaques de déni de service applicatif, à l'extraction massive de données, et aux abus consommant des ressources coûteuses (appels à des services tiers facturés, opérations computationnellement intensives). Les ressources non protégées incluent : le nombre de requêtes par unité de temps (rate limiting absent), la taille des payloads (upload illimité entraînant saturation mémoire ou disque), la profondeur des requêtes récursives (GraphQL, JSON deeply nested), le nombre d'objets retournés par une requête de liste (pagination absente ou illimitée), les ressources de tiers facturées par utilisation (APIs d'envoi d'email, SMS, traduction), et le temps de traitement des opérations intensives (génération PDF, redimensionnement d'image, calculs cryptographiques). La protection contre les ressources non restreintes passe par : le rate limiting multi-dimensional (par IP, par token, par endpoint), la limitation de la taille des payloads (limite configurée dans le reverse proxy ou l'API Gateway), la pagination obligatoire pour toutes les listes avec limite maximale configurable, les timeouts de requête pour limiter les opérations longues, et les quotas par client pour les ressources facturées.

Dimensions de la consommation de ressources non restreinte

L'API4 couvre plusieurs dimensions de risque : volume de requêtes (DDoS applicatif par saturation des workers), taille des payloads (parsing de JSON/XML géant saturant la RAM), pagination sans limite (téléchargement de toute la base via /api/products?limit=999999), profondeur GraphQL (requêtes récursives générant des requêtes DB exponentielles), et opérations coûteuses (appels à des LLM, génération de rapports, envois d'emails en masse via des endpoints publics). Chaque dimension nécessite des contrôles spécifiques.

Implémentation des contrôles de ressources

Contrôles recommandés : Rate Limiting via Redis ou l'API Gateway (token bucket par IP + par utilisateur), Content-Length maximum (rejeté par le reverse proxy avant parsing applicatif), pagination forcée (limit par défaut = 20, max = 100, avec curseur ou offset), limits de profondeur GraphQL (max-depth = 7), timeout de requête (30s pour les opérations normales, 300s pour les exports), et throttling des opérations coûteuses (file d'attente avec priorité pour les opérations asynchrones lourdes).

Protection des ressources tierces facturées

Les APIs exposant des ressources tierces facturées (envoi SMS, LLM calls, analyses d'images) nécessitent des quotas par client avec alertes de dépassement. Un utilisateur malveillant pourrait déclencher des milliers d'envois SMS ou d'appels OpenAI si ces endpoints ne sont pas protégés. Des implémentations préventives : quota mensuel par compte (avec UI de suivi), pré-validation légère avant l'opération coûteuse (vérifier le destinataire avant l'envoi SMS), et mode async (jobs en file d'attente) pour les opérations susceptibles d'être abusées.

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis