CWE-862 : autorisation manquante, le contrôle qui n’a jamais été écrit

Quatrième du CWE Top 25 2025, en progression de cinq places sur l’édition précédente, la plus forte montée du classement. Le libellé officiel est sobre : Missing Authorization, « autorisation manquante ». Le catalogue retient l’abréviation AuthZ, qui sert surtout à la distinguer de AuthN, l’authentification, confusion qui fait l’essentiel des malentendus de ce domaine.

→ Lire l’explication complète de la marmotte

Ce que la classe recouvre exactement

Le produit n’effectue aucune vérification d’autorisation lorsqu’un acteur tente d’accéder à une ressource ou d’exécuter une action. La définition ne comporte ni nuance ni degré : le contrôle est absent.

Cette brutalité est précisément ce qui rend la classe utile, car elle la sépare nettement de sa sœur. Dans CWE-862, personne n’a écrit le contrôle. Dans CWE-863, l’autorisation incorrecte, le contrôle existe mais se trompe : il interroge le mauvais attribut, compare au mauvais moment, ou applique une règle qui ne couvre pas le cas rencontré. Les deux produisent le même résultat pour la victime, mais pas le même ticket pour l’équipe : l’une doit écrire du code, l’autre doit comprendre une logique existante. C’est aussi pourquoi le classement les sépare, au rang 4 et au rang 17.

Deuxième distinction, celle qu’on rate le plus souvent : CWE-862 n’est pas CWE-306, l’authentification manquante sur une fonction critique. L’authentification établit qui parle ; l’autorisation décide ce qu’il a le droit de faire. Une application peut parfaitement authentifier tout le monde très sérieusement, puis laisser le premier compte créé lire les dossiers de tous les autres. Dans un rapport d’audit, « il n’y a pas d’authentification » et « il n’y a pas d’autorisation » appellent des corrections qui ne se ressemblent pas.

Sa place dans l’arbre

CWE-862 est une classe : elle décrit un mécanisme sans préjuger de la technologie. Son parent dans la vue de recherche est CWE-285, autorisation incorrecte au sens large, elle-même rattachée au pilier CWE-284, le contrôle d’accès défaillant. Trois des quatre étages de cette branche figurent simultanément au Top 25, ce qui en dit long sur la façon dont les déclarants rangent leurs vulnérabilités.

Quatre entrées descendent d’elle, et chacune nomme une situation reconnaissable :

CWE-425, la requête directe, dite aussi navigation forcée : la page d’administration n’est pas liée dans le menu, donc personne ne l’a protégée, l’adresse devinée suffit ;
CWE-638, l’absence de médiation complète : le contrôle existe à l’entrée principale, mais pas sur les chemins secondaires, notamment l’API qui sert la même ressource que la page web ;
CWE-939, l’autorisation défaillante dans le gestionnaire d’un schéma d’URL personnalisé, le cas mobile, où une application ouvre une action sensible sur simple appel d’une autre application ;
CWE-1314, l’absence de protection en écriture sur des valeurs de configuration matérielle.

Pourquoi elle monte si vite

L’explication tient en un mot : les API.

Une interface web monolithique concentre ses contrôles dans quelques points de passage ; une application découpée en dizaines de services expose des dizaines de points d’entrée, et chacun doit porter sa propre vérification. Le défaut apparaît alors non pas par ignorance, mais par asymétrie : la page web vérifie, l’API qui alimente la même page ne vérifie pas, parce que ses auteurs la croyaient interne. Les référentiels applicatifs ont acté ce basculement : le Top 10 des API de l’OWASP place l’autorisation à ses trois premiers rangs, au niveau de l’objet, de la fonction et de la propriété.

Deux effets secondaires accélèrent la montée. Les programmes de récompense de vulnérabilités adorent ce défaut, qui se démontre en deux requêtes et sans outillage, donc il se déclare beaucoup. Et son attribution est plus facile qu’avant : l’édition 2025 du classement a réanalysé un quart des vulnérabilités pour corriger les attributions trop vagues, et une partie de ce qui dormait sous des classes génériques a basculé ici.

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

Le site traite ce défaut par son cas le plus fréquent : prévenir les BOLA dans une API métier montre l’identifiant d’objet qu’on remplace et le contrôle qui manque, ce qui est exactement cette classe vue du côté de l’API. Pour le choix du modèle qui porte la décision, DAC, MAC, RBAC, ABAC ou ReBAC compare les familles, et ReBAC Zanzibar décrit l’approche qui centralise les autorisations relationnelles fines plutôt que de les disperser dans le code.

Deux renvois pour les environnements concrets : réduire RBAC Kubernetes pour un plan de contrôle où l’absence de règle équivaut souvent à la permission, et auditer l’héritage des permissions pour les systèmes où le droit effectif ne se lit nulle part et doit être calculé.

Ce qu’une équipe en fait

Refuser par défaut. C’est le seul contrôle qui traite la cause : une ressource sans règle explicite est inaccessible. Un cadre applicatif où l’oubli se traduit par une interdiction transforme la faiblesse en incident de développement ; un cadre où l’oubli se traduit par une permission la transforme en vulnérabilité publiée.

Décider en un seul endroit. Une fonction d’autorisation unique, appelée par tous les points d’entrée, se relit et se teste ; une vérification recopiée dans chaque gestionnaire de requête se perd dès la troisième copie.

Tester la négative. Les tests automatisés vérifient ordinairement que l’utilisateur autorisé obtient la ressource. Il faut autant de tests pour vérifier que l’utilisateur non autorisé ne l’obtient pas, sur chaque point d’entrée, y compris ceux que l’interface n’expose pas. C’est le seul moyen de détecter l’asymétrie entre la page et l’API qui la sert.

Sources

CWE-862: Missing Authorization, MITRE, liste 4.20 : définition, parents et entrées filles.
2025 CWE Top 25, MITRE : rang 4, en progression de cinq places.

🐝 Ce qui arrive si on s’en passe

Une équipe qui ne distingue pas l’authentification de l’autorisation livre une application où tout utilisateur connecté est, de fait, administrateur de ce qu’il parvient à demander. Le défaut ne se voit pas à l’usage : l’interface ne propose à chacun que ses propres données, et tant que personne ne modifie une adresse à la main, tout fonctionne. Il se découvre généralement par un client qui tombe par accident sur le dossier d’un autre client, ce qui transforme un défaut technique en incident de confiance, puis en notification réglementaire s’il s’agit de données personnelles. Le coût de rattrapage est élevé pour une raison structurelle : il ne suffit pas d’ajouter un contrôle, il faut d’abord établir qui a le droit de quoi, décision que personne n’a prise au moment de la conception et que l’équipe de développement n’a pas qualité pour prendre seule.

🦫 Explication de la marmotte 🍫

Deux vérifications différentes protègent un service informatique. La première, l’authentification, répond à la question « qui êtes-vous ? » : c’est le mot de passe, le code reçu par téléphone, la clé de sécurité. La seconde, l’autorisation, répond à la question « avez-vous le droit de faire cela ? » : votre compte existe bien, mais ce dossier n’est pas le vôtre.

Beaucoup d’applications font très soigneusement la première et oublient la seconde. Elles vérifient que vous êtes connecté, puis exécutent ce que vous demandez sans se demander si vous y avez droit. Tant que vous cliquez sur les boutons prévus, vous ne voyez que vos propres informations, et rien ne révèle le problème. Mais l’adresse d’une page contient souvent un numéro de dossier : en le changeant, on demande le dossier du voisin, et l’application le fournit, puisqu’elle n’a aucune règle pour refuser.

C’est ce défaut que le catalogue CWE appelle CWE-862, « autorisation manquante ». Il faut le distinguer de son cousin CWE-863, où la vérification existe mais se trompe : ici, elle n’a simplement jamais été écrite.

Ce défaut progresse fortement dans le classement annuel, pour une raison liée à la façon dont les logiciels sont construits aujourd’hui. Une application moderne n’est plus un programme unique mais un assemblage de services qui se parlent, et chacun de ces services doit vérifier les droits de son côté. Il suffit que l’un d’eux ait été écrit en supposant que « de toute façon, seuls nos propres programmes l’appellent » pour que la porte reste ouverte : car un programme appelable par l’application est généralement appelable par n’importe qui.

Pages voisines

La citent

CWE-862 : autorisation manquante, le contrôle qui n'a jamais été écrit

Elle cite

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