CWE-284 : contrôle d’accès défaillant, le pilier venu de l’OWASP

Dix-neuvième du CWE Top 25 2025. Le libellé officiel est Improper Access Control, « contrôle d’accès défaillant ». C’est l’un des dix piliers du catalogue, c’est-à-dire l’un de ses niveaux les plus abstraits : et le MITRE en déconseille formellement l’usage pour classer une vulnérabilité. Il faut donc expliquer pourquoi elle se trouve là, et la réponse est intéressante : elle vient d’ailleurs.

→ Lire l’explication complète de la marmotte

Ce que le pilier recouvre

Le produit ne restreint pas, ou restreint incorrectement, l’accès à une ressource depuis un acteur non autorisé. En une phrase : tout le contrôle d’accès.

Un pilier n’est pas fait pour désigner un défaut, mais pour organiser le catalogue. Sous CWE-284 vivent toutes les branches de la restriction d’accès, et elles sont d’une variété considérable : l’autorisation applicative avec ses deux versants (manquante et incorrecte), mais aussi le contrôle d’accès physique, les interfaces de débogage laissées ouvertes sur une puce, les champs de registres matériels insuffisamment protégés, les bits de verrouillage modifiables, les jetons de sécurité mal assignés. Une bonne partie de sa descendance directe concerne le silicium, pas le logiciel.

C’est la première chose à savoir devant un rapport qui cite ce numéro : il peut désigner un défaut d’autorisation dans une API web ou une interface de test laissée active dans un processeur, et rien dans le code ne permet de distinguer les deux.

Pourquoi son usage est déconseillé, et d’où vient sa présence au classement

La note de mappage du MITRE est explicite et nomme la cause. CWE-284 est, selon ses termes, « extrêmement général, un pilier », et son nom est « souvent mal employé dans les rapports pauvres en information ou par usage actif du Top 10 de l’OWASP, comme A01:2021-Broken Access Control ». Le catalogue ajoute qu’elle n’est pas utile à l’analyse de tendance, et recommande d’employer un descendant plus spécifique.

Ce passage mérite d’être lu deux fois, car il décrit un phénomène de contamination entre catalogues. Le Top 10 web de l’OWASP place en première position une catégorie nommée « contrôle d’accès défaillant », qui regroupe par construction des dizaines de faiblesses distinctes, car c’est son rôle : prioriser des risques, pas désigner des défauts. Lorsqu’une organisation adopte ce vocabulaire pour ses déclarations, elle attribue naturellement à ses vulnérabilités le CWE qui porte le même nom. La catégorie de priorisation devient une cause racine, par homonymie.

Le rang 19 de ce pilier n’est donc pas la mesure d’un danger : c’est la trace, dans les données, de l’usage d’un autre référentiel. C’est l’exemple le plus net de ce que le classement mesure vraiment : les pratiques de déclaration autant que les faiblesses.

Sa place dans l’arbre

Il n’y a rien au-dessus : c’est un pilier. En dessous, la branche la plus fréquentée en sécurité applicative passe par la classe CWE-285, l’autorisation incorrecte au sens large (elle-même d’usage déconseillé, étant une classe de premier niveau), puis par les deux classes sœurs du Top 25, puis par les bases qui désignent enfin quelque chose de concret, comme CWE-639, le contournement par clé contrôlée par l’utilisateur.

Quatre entrées de cette seule branche figurent au classement, aux rangs 4, 17, 19 et 24, ce que le schéma de la page chapeau représente étage par étage. Un lecteur pressé y voit quatre problèmes ; il y en a un, déclaré à quatre hauteurs.

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

Il n’y a pas de mécanisme propre à un pilier, mais une question de conception que le site traite au bon niveau : DAC, MAC, RBAC, ABAC ou ReBAC compare les modèles et dit lequel sait exprimer quelle règle, ce qui est la décision d’où découlent toutes les faiblesses de la branche.

Pour les trois terrains où ce pilier se manifeste concrètement, trois renvois : réduire RBAC Kubernetes et bloquer les pods dangereux côté plateforme, auditer l’héritage des permissions et le droit effectif côté annuaire, et filtrage, segmentation, NAC et Zero Trust côté réseau, car la restriction d’accès ne se joue pas seulement dans le code.

Pour le versant matériel de sa descendance, SGX et TrustZone pour isoler du code sensible donne une idée de ce que « contrôle d’accès » veut dire quand il s’agit de silicium.

Ce qu’une équipe en fait

Refuser ce numéro dans un ticket. Un rapport qui cite CWE-284 n’a pas identifié le défaut. La question utile est : le contrôle est-il absent, présent mais faux, ou contourné par un chemin secondaire ? Les trois réponses mènent à trois corrections différentes.

Se méfier de l’homonymie entre catalogues. « Broken access control » dans un rapport peut renvoyer à la catégorie OWASP, utile pour prioriser, ou au pilier CWE, inutilisable pour corriger. Les deux portent le même nom et ne servent pas au même usage ; un rapport sérieux précise de quel référentiel il parle, et dans quelle version.

Décider où vit la règle. La plupart des faiblesses de cette branche viennent d’une décision jamais prise : qui, dans le système, détient la politique d’accès. Tant que la réponse est « chaque service à sa façon », les quatre rangs du classement continueront d’être alimentés.

Sources

CWE-284: Improper Access Control, MITRE, liste 4.20 : définition, statut de pilier, note de mappage « Discouraged » citant A01:2021 de l’OWASP.
2025 CWE Top 25, MITRE : rang 19.

🐝 Ce qui arrive si on s’en passe

Une organisation qui ne distingue pas un pilier d’une base pilote sa sécurité applicative sur un indicateur creux. Le tableau de bord annonce « 38 % de nos vulnérabilités relèvent du contrôle d’accès défaillant », chiffre impressionnant qui ne permet de décider de rien : ni une formation, puisqu’on ne sait pas si l’équipe oublie les contrôles ou les écrit de travers ; ni un outil, puisque la détection d’une autorisation absente et celle d’une autorisation fausse n’emploient pas les mêmes techniques ; ni une correction, puisque le ticket ne désigne aucun code. Le coût réel est le temps perdu en réunions à discuter d’un pourcentage, pendant que les quatre défauts concrets qu’il recouvre restent en production, chacun avec son correctif précis, connu, et non appliqué.

🦫 Explication de la marmotte 🍫

Le catalogue CWE des défauts logiciels est organisé comme un arbre. En haut, dix grandes idées très générales, appelées piliers. En dessous, des familles. Plus bas encore, les défauts précis, ceux qui désignent une erreur qu’un développeur peut corriger.

CWE-284 est un pilier : il signifie « l’accès à une ressource n’est pas correctement restreint ». C’est vrai de milliers de situations différentes, depuis un site web qui laisse consulter le dossier du voisin jusqu’à une puce électronique dont l’interface de test est restée accessible. Dire d’une faille qu’elle relève de CWE-284, c’est dire d’une panne de voiture qu’elle relève de la mécanique.

L’organisme qui tient le catalogue déconseille donc explicitement d’employer ce numéro pour classer une faille, et il explique au passage pourquoi on le fait quand même. Une autre organisation, l’OWASP, publie une liste des dix risques les plus répandus des applications web ; son premier item porte justement le nom « contrôle d’accès défaillant ». Cette liste sert à décider par quoi commencer, ce qui est fort utile. Mais les équipes qui l’emploient attribuent ensuite à leurs failles le numéro du catalogue CWE qui porte le même nom, de sorte qu’une catégorie de priorités se transforme en cause technique.

C’est pourquoi la dix-neuvième place de cette entrée dans le classement annuel ne dit rien sur le danger, et beaucoup sur la façon dont les rapports sont rédigés. La leçon pratique est simple : devant un rapport qui cite ce numéro, il faut demander lequel des trois cas réels est en cause, le contrôle n’existe pas, il existe mais se trompe, ou il existe et un autre chemin l’évite.

Pages voisines

La citent

CICD-SEC-1 : mécanismes de contrôle de flux insuffisants

CWE-284 : contrôle d'accès défaillant, le pilier venu de l'OWASP

Elle cite

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