Aller au contenu
TortueTech
RubriquesRéférentiels & catalogues

CWE-863 : autorisation incorrecte, le contrôle qui vérifie la mauvaise chose

CWE-863 : autorisation incorrecte, le contrôle qui vérifie la mauvaise chose

Section intitulée « CWE-863 : autorisation incorrecte, le contrôle qui vérifie la mauvaise chose »

Dix-septième du CWE Top 25 2025. Le libellé officiel est Incorrect Authorization, « autorisation incorrecte ». Elle est la sœur de l’autorisation manquante, classée au rang 4, et toute l’utilité de la paire tient à leur différence : ici, le contrôle a été écrit. Il est simplement faux.

→ 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 effectue une vérification d’autorisation lorsqu’un acteur tente d’accéder à une ressource ou d’exécuter une action, mais cette vérification ne garantit pas la décision correcte.

La différence avec sa sœur est donc d’origine, pas d’effet. L’attaquant obtient la même ressource dans les deux cas ; mais une autorisation manquante se corrige en ajoutant un contrôle, tandis qu’une autorisation incorrecte se corrige en comprenant d’abord pourquoi le contrôle existant se trompe. C’est un travail d’une autre nature, et c’est pourquoi le catalogue refuse de les confondre.

Quatre façons de se tromper reviennent constamment :

  • vérifier la mauvaise propriété : contrôler que l’utilisateur a un rôle, alors que la question était de savoir si cette ressource-là lui appartient ;
  • vérifier au mauvais moment : décider avant d’avoir résolu ce sur quoi l’on décide, défaut dont le catalogue a fait une entrée à part entière, CWE-551, l’ordre de comportement incorrect ;
  • vérifier sur une donnée que l’appelant contrôle : c’est le cas de CWE-639, le contournement par clé contrôlée par l’utilisateur, au rang 24 ;
  • vérifier correctement, mais pas partout : la règle est juste et l’un des chemins d’accès ne l’applique pas. Ce cas-là relève plutôt de l’autorisation manquante sur ce chemin, et c’est la frontière la plus discutée des deux classes.

Sa place dans l’arbre

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

CWE-863 est une classe, fille de CWE-285 (autorisation incorrecte au sens large) et rattachée au pilier CWE-284, le contrôle d’accès défaillant, lui-même au rang 19. Elle est donc le deuxième étage d’une branche dont trois niveaux figurent au classement, situation qui mérite d’être lue pour ce qu’elle est : non pas trois problèmes, mais un seul, déclaré à trois finesses différentes.

Sept entrées descendent d’elle, dont quatre valent d’être connues :

  • CWE-639, le contournement par clé contrôlée par l’utilisateur, déjà cité ;
  • CWE-551, la vérification faite avant la résolution, par exemple contrôler les droits sur un chemin avant de le canonicaliser, ce qui relie cette branche à la traversée de chemin ;
  • CWE-942, la politique de partage entre origines trop permissive : un contrôle existe, il autorise simplement tout le monde ;
  • CWE-647, l’usage de chemins d’URL non canoniques pour décider des droits, qui est la version web du même défaut de résolution.

Pourquoi elle est si haut

Section intitulée « Pourquoi elle est si haut »

Parce que les règles d’autorisation sont devenues des données. Dans les systèmes modernes, la décision dépend de rôles, de groupes, d’attributs, de relations et de hiérarchies, souvent stockés dans plusieurs référentiels. Le code ne contient plus la règle mais l’interrogation d’un modèle, et il devient très facile d’interroger correctement une règle fausse.

Parce que la délégation d’autorisation multiplie les occasions. Jetons porteurs d’étendues, assertions fédérées, échanges de jetons entre services : chaque étape ajoute une vérification, et chaque vérification peut porter sur le mauvais champ. Le site en documente deux cas exemplaires, la confusion d’étendue OAuth et l’assertion fédérée injectée, où une signature parfaitement valide ne dit pas ce que le vérificateur croit lire.

Parce que ces défauts résistent aux tests. Les tests d’autorisation vérifient qu’un utilisateur autorisé passe et qu’un utilisateur anonyme est refusé. Le cas de cette classe est le troisième : un utilisateur légitime qui demande la ressource d’un autre utilisateur légitime. Il n’est presque jamais couvert, parce qu’il suppose un jeu de données avec deux comptes et deux jeux de ressources.

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

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

Pour le modèle de décision, DAC, MAC, RBAC, ABAC ou ReBAC explique quelle famille répond à quelle question : et c’est bien le choix de la famille qui détermine si l’on pourra exprimer la règle juste. ReBAC Zanzibar décrit l’approche qui convient aux autorisations relationnelles, celles qui demandent « cette ressource appartient-elle à cet utilisateur ».

Pour le calcul du droit effectif, qui est le cœur des erreurs silencieuses, auditer l’héritage des permissions montre comment un droit juste au départ devient faux par héritage, et pourquoi personne ne s’en aperçoit.

Pour les deux cas de délégation, la confusion d’étendue OAuth et l’échange de jetons, délégation ou usurpation traitent les situations où la vérification existe et porte sur le mauvais élément. Enfin, pour le cas du partage entre origines, la politique de même origine explique ce qu’une configuration permissive abandonne.

Ce qu’une équipe en fait

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

Rendre la règle explicite et unique. Une politique écrite à un seul endroit, qui répond à la question « cet acteur peut-il faire cette action sur cette ressource », se relit et se teste. Une décision dispersée en vingt conditions dans vingt gestionnaires de requêtes ne se vérifie pas.

Décider après résolution, jamais avant. La règle vaut pour les chemins de fichiers, les adresses, les identifiants d’objet : on identifie d’abord la ressource réelle, on décide ensuite. L’ordre inverse est une entrée du catalogue à lui seul.

Tester le cas du tiers légitime. Deux comptes, deux jeux de données, et un test par point d’entrée vérifiant que le premier n’atteint pas les ressources du second. C’est le test que personne n’écrit et qui trouve cette classe entière.

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 distingue pas le contrôle absent du contrôle faux conclut de la présence d’un contrôle que le sujet est traité. L’audit coche la ligne « une vérification d’autorisation est en place », les tests passent, et la règle appliquée n’est pas celle qu’on croit. Le défaut se découvre par l’usage : un utilisateur voit les données d’un autre, et la question posée à l’équipe n’est pas technique mais politique, qui, dans l’organisation, avait décidé que ce droit existait ? Personne, et c’est là le vrai coût : il faut d’abord établir la règle juste, exercice qui mobilise le métier, le juridique et l’exploitation, avant même d’écrire une ligne. Pendant ce temps, le contrôle fautif reste en place, car le désactiver bloquerait des accès légitimes dont personne ne connaît la liste.

🦫 Explication de la marmotte 🍫

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

Pour protéger une ressource informatique, il faut répondre à deux questions successives : qui êtes-vous, et avez-vous le droit d’y accéder ? La première s’appelle l’authentification, la seconde l’autorisation.

Il existe deux façons de rater la seconde. La première consiste à ne pas la poser du tout : c’est le défaut CWE-862. La seconde consiste à la poser mal, et c’est celui-ci, CWE-863.

Mal poser la question prend plusieurs formes. On peut vérifier que la personne appartient bien au service comptable, alors que la vraie question était de savoir si cette facture-là la concerne. On peut vérifier les droits sur le nom de fichier demandé, puis découvrir que ce nom désignait en réalité un autre fichier. On peut vérifier un élément que le demandeur a lui-même fourni, et qu’il peut donc changer. Dans tous les cas, la vérification a bien eu lieu : elle portait sur autre chose que ce qu’il fallait.

Ce défaut est particulièrement tenace, pour deux raisons. D’abord, sa présence rassure : un contrôle existe, il figure dans la documentation, l’auditeur le constate. Ensuite, il échappe aux tests habituels, qui vérifient qu’un utilisateur autorisé obtient ce qu’il demande et qu’un inconnu est refusé : jamais qu’un utilisateur légitime n’obtient pas les données d’un autre utilisateur légitime. C’est pourtant ce troisième essai, qui demande simplement deux comptes et un peu de curiosité, qui révèle presque toujours le problème.

À lire aussi

Pages voisines

La citent

CWE-863 : autorisation incorrecte, le contrôle qui vérifie la mauvaise chose

Elle cite

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