Aller au contenu
TortueTech
RubriquesRéférentiels & catalogues

CWE-770 : allocation de ressources sans limite ni régulation

CWE-770 : allocation de ressources sans limite ni régulation

Section intitulée « CWE-770 : allocation de ressources sans limite ni régulation »

Vingt-cinquième et dernière du CWE Top 25 2025. Le libellé officiel est Allocation of Resources Without Limits or Throttling, « allocation de ressources sans limite ni régulation ». C’est la seule entrée du classement qui ne concerne ni la confidentialité ni l’intégrité : elle parle de disponibilité, et accessoirement, depuis quelques années, de facture.

→ Lire l’explication complète de la marmotte

Ce que la classe recouvre exactement

Section intitulée « Ce que la classe recouvre exactement »

Le produit alloue une ressource réutilisable, ou un ensemble de ressources, pour le compte d’un acteur, sans imposer de restriction sur la taille ou le nombre de ressources allouables.

La définition couvre deux limites distinctes, et les deux sont nécessaires :

  • la taille : une seule allocation dont la dimension est dictée de l’extérieur. Un en-tête qui annonce un contenu de plusieurs gigaoctets, une image dont les dimensions déclarées imposent un tampon démesuré, une requête qui demande un million d’enregistrements d’un coup ;
  • le nombre : des allocations unitairement raisonnables, mais répétées sans compteur. Connexions, fils d’exécution, sessions, descripteurs de fichiers, entrées de cache, tâches en file d’attente.

Le mot « régulation » ajoute une troisième dimension, temporelle : il ne suffit pas de borner le total, il faut aussi borner le débit. Un service qui autorise mille créations de compte au total mais mille par seconde n’a pas de limite utile.

À noter, car c’est contre-intuitif : le second parent de cette entrée est CWE-665, l’initialisation incorrecte. Le catalogue considère donc qu’une partie de ces défauts tient à une ressource mise en place sans que ses bornes aient été fixées : l’absence de limite est un défaut de configuration initiale autant qu’un défaut de code.

Sa place dans l’arbre

Section intitulée « Sa place dans l’arbre »

CWE-770 est une base, fille principale de la classe CWE-400, « consommation incontrôlée de ressources ». Le catalogue lui attribue la mention de mappage « admise » : elle se trouve au niveau d’abstraction recommandé pour désigner une cause racine, ce qui la distingue des classes trop générales du classement.

Trois entrées filles nomment les cas les plus fréquents :

  • CWE-789, l’allocation mémoire d’une taille excessive, la limite de taille qui manque ;
  • CWE-774, l’allocation de descripteurs de fichiers ou de poignées sans limite : le défaut qui épuise une ressource système partagée plutôt que la mémoire, et dont les symptômes sont les plus déroutants, car le service tombe en annonçant qu’il ne peut plus ouvrir de fichier ;
  • CWE-1325, l’allocation séquentielle mal contrôlée, où chaque itération d’une boucle alloue un peu plus.

Une voisine mérite d’être citée : CWE-674, la récursion non contrôlée, qui épuise la pile par un autre chemin. Elle est le second sens de l’expression « stack overflow », dont la page sur le débordement de pile explique la confusion.

Pourquoi elle figure au classement

Section intitulée « Pourquoi elle figure au classement »

Parce que l’élasticité a transformé la panne en dépense. Sur une infrastructure fixe, une consommation non bornée produit une panne, visible et bornée dans le temps. Sur une infrastructure qui s’adapte à la charge, elle produit une facture, qui croît sans que rien ne tombe. Le site traite cette mutation sous deux angles : les quotas cloud contre le déni de service par coût et la gouvernance des coûts comme sécurité indirecte.

Parce que les API d’intelligence artificielle ont donné à ce défaut sa forme la plus moderne. Une application qui relaie des requêtes vers un modèle facturé à l’usage, sans compteur par utilisateur, offre un budget à qui veut le dépenser : c’est le denial of wallet, que le site documente. La ressource allouée sans limite n’est plus de la mémoire, c’est de l’argent.

Parce que l’absence de limite n’est jamais signalée par un test. Aucune suite de tests ne constate qu’une fonction n’a pas de borne : tout passe, et d’autant mieux que les tests sont petits. Le défaut ne se découvre qu’en charge, c’est-à-dire en production.

Parce que les limites posées sont souvent contournables. Un plafond appliqué par adresse IP, par session ou par en-tête se défait en changeant la clé de comptage, comme le montre le contournement de limite de débit par rotation d’en-têtes.

Le mécanisme, et où le site le traite

Section intitulée « Le mécanisme, et où le site le traite »

Pour la défense applicative, mettre en place un rate limiting anti-DDoS de couche 7 est la page de référence : quelle clé de comptage, quel algorithme, quel comportement au dépassement. Pour la vue d’ensemble des attaques de saturation, défendre un DDoS volumétrique et applicatif distingue ce qui se traite par la capacité de ce qui se traite par la logique : cette classe appartient à la seconde catégorie, puisqu’une seule requête bien formée peut suffire.

Pour la détection, repérer un moissonnage applicatif décrit les signaux (volumétrie, cadence, origine), qui distinguent un usage intensif d’un abus.

Ce qu’une équipe en fait

Section intitulée « Ce qu’une équipe en fait »

Borner chaque allocation à l’entrée. Taille maximale de corps de requête, de fichier téléversé, de page de résultats, de profondeur de requête imbriquée : ces plafonds sont des décisions de produit, pas des réglages techniques, et ils doivent être écrits quelque part avant d’être codés.

Compter par identité, pas par adresse. La clé de comptage doit être la plus proche possible de l’acteur réel : compte, clé d’API, abonnement. L’adresse réseau est la clé la moins coûteuse à changer pour qui veut contourner la limite.

Poser des quotas au niveau de la plateforme, en plus de l’application : limites de dépense, nombre maximal d’instances, plafonds par service. C’est le filet qui tient quand la limite applicative est oubliée sur un nouveau point d’entrée.

Décider du comportement au dépassement. Refuser proprement avec un code d’erreur explicite et un délai d’attente indiqué, plutôt que ralentir indéfiniment : un service qui ralentit tout le monde pour servir un abuseur a transformé un abus en panne générale.

Sources

Section intitulée « Sources »

🐝 Ce qui arrive si on s’en passe

Section intitulée « 🐝 Ce qui arrive si on s’en passe »

Une équipe qui ne pose pas de limites livre un service qui fonctionne parfaitement jusqu’au jour où quelqu’un s’en sert beaucoup. Sur une infrastructure classique, la conséquence est une panne, déclenchable à volonté par n’importe qui, sans compte ni compétence, et que les défenses anti-saturation ne voient pas puisqu’il suffit parfois d’une seule requête bien construite. Sur une infrastructure facturée à l’usage, la conséquence est plus insidieuse : rien ne tombe, les tableaux de bord techniques restent verts, et le problème se découvre à la facture du mois suivant, c’est-à-dire plusieurs semaines après le début de l’abus, quand la dépense est déjà engagée et qu’il faut expliquer à la direction financière qu’un paramètre manquant a coûté un trimestre de budget. Dans les deux cas, la correction d’urgence consiste à poser une limite sans savoir laquelle, ce qui revient à choisir entre laisser passer l’abus et refuser des clients légitimes.

🦫 Explication de la marmotte 🍫

Section intitulée « 🦫 Explication de la marmotte 🍫 »

Pour répondre à une demande, un programme consomme des ressources : de la mémoire, du temps de calcul, des connexions, parfois des services payants qu’il appelle à l’extérieur.

Le défaut consiste à ne fixer aucune limite : ni sur la taille de ce qu’une seule demande peut réclamer, ni sur le nombre de demandes qu’une même personne peut enchaîner. Tant que les utilisateurs se comportent raisonnablement, personne ne remarque rien. Le jour où quelqu’un décide d’en profiter, le service s’épuise.

C’est le défaut que le catalogue CWE appelle CWE-770. Il concerne la disponibilité : il ne divulgue rien et n’abîme rien, il empêche de fonctionner. Avec une particularité qui le rend difficile à anticiper : il ne faut pas forcément un grand nombre de demandes. Une seule requête annonçant un contenu de plusieurs milliards de caractères, ou demandant un million de résultats, peut suffire : ce qui échappe à toutes les protections qui surveillent le volume de trafic.

Ce défaut a changé de nature avec l’informatique en nuage. Autrefois, une consommation excessive faisait tomber le serveur, panne visible et vite constatée. Aujourd’hui, l’infrastructure s’adapte automatiquement à la demande : elle ajoute des machines, et rien ne tombe. Le problème se manifeste alors sous la forme d’une facture, plusieurs semaines plus tard. La variante la plus récente concerne les services d’intelligence artificielle, facturés à l’usage : une application qui les relaie sans compteur par utilisateur met son budget à la disposition du public.

La parade consiste à fixer des bornes explicites (taille maximale d’une demande, nombre maximal de demandes par compte et par minute), et à les compter par identité plutôt que par adresse réseau, cette dernière étant la chose la plus facile à changer pour qui veut contourner la règle.

À lire aussi

Pages voisines

La citent

CWE-770 : allocation de ressources sans limite ni régulation

Elle cite

: les deux pages se citent l’une l’autre.