CWE-639 : contournement d’autorisation par clé contrôlée par l’utilisateur (IDOR, BOLA)

Vingt-quatrième du CWE Top 25 2025. Le libellé officiel est Authorization Bypass Through User-Controlled Key, « contournement d’autorisation par une clé contrôlée par l’utilisateur ». Cette entrée détient un record : trois appellations concurrentes, toutes en usage, pour le même défaut, à savoir IDOR (référence directe non sécurisée à un objet), BOLA (autorisation défaillante au niveau de l’objet) et autorisation horizontale. Le catalogue les enregistre toutes les trois comme termes alternatifs.

→ Lire l’explication complète de la marmotte

Ce que la classe recouvre exactement

La fonction d’autorisation du système n’empêche pas un utilisateur d’accéder aux données ou à l’enregistrement d’un autre utilisateur en modifiant la valeur de la clé qui identifie la donnée.

Il faut noter ce que cette définition suppose : l’utilisateur est authentifié, il a le droit d’utiliser la fonction, et il l’utilise normalement. Il change seulement un paramètre. C’est pourquoi on parle d’autorisation horizontale : il ne s’élève pas en privilèges, il se déplace latéralement vers les données de ses pairs.

Le défaut n’est pas que l’identifiant soit visible ou prévisible. Un identifiant séquentiel rend l’exploitation triviale, et c’est pourquoi on recommande des identifiants opaques ; mais remplacer un identifiant devinable par un identifiant aléatoire ne corrige pas la faiblesse, cela la rend plus difficile à trouver. Le défaut est l’absence de vérification du lien entre l’acteur qui demande et la ressource demandée. C’est la confusion la plus coûteuse du domaine, parce qu’elle conduit à livrer une correction qui ne corrige rien.

Sa place dans l’arbre

CWE-639 est une base, fille de CWE-863, l’autorisation incorrecte : la vérification existe (l’utilisateur est bien authentifié, la fonction est bien contrôlée), mais elle ne porte pas sur la bonne chose. Elle est rattachée, plus haut, au pilier CWE-284.

Le catalogue attribue à cette entrée la mention de mappage « admise », avec le commentaire qui explique sa présence au classement : elle se situe au niveau base, « le niveau d’abstraction préféré pour désigner les causes racines des vulnérabilités ». Autrement dit, c’est l’une des entrées de cette branche que le MITRE encourage à employer, là où il déconseille le pilier et la classe de premier niveau. Sa vingt-quatrième place, acquise malgré une gravité souvent jugée moyenne, traduit donc un progrès dans la façon de déclarer plutôt qu’une épidémie nouvelle.

Une variante descend d’elle, CWE-566, qui applique le même défaut à l’accès à une base de données par une clé contrôlée.

Pourquoi elle est si fréquente

Parce que les API exposent les identifiants par conception. Une interface qui respecte les conventions courantes place l’identifiant de la ressource dans l’adresse. C’est une bonne pratique d’architecture, et elle rend le paramètre visible, lisible et modifiable : il n’y a là aucun défaut, seulement l’obligation de vérifier l’appartenance à chaque appel. Le Top 10 des API de l’OWASP place ce défaut à son premier rang, sous le nom de BOLA.

Parce que la vérification doit être répétée partout. Chaque point d’entrée qui accepte un identifiant doit poser la question de l’appartenance. Un seul oubli suffit, et les oublis se concentrent sur les chemins secondaires : l’export, l’aperçu, la pièce jointe, la version imprimable, l’API mobile.

Parce que les tests ne la voient pas. Un test écrit avec un seul compte vérifie que l’utilisateur accède à ses données. Il faut deux comptes pour constater qu’il accède aussi à celles de l’autre, et ce jeu de données n’existe presque jamais dans les suites de tests.

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

Le site traite précisément ce défaut dans prévenir les BOLA dans une API métier : l’identifiant remplacé, le contrôle manquant, et la manière de le poser au bon endroit. Il n’y a rien à ajouter sur le mécanisme.

Pour le modèle qui permet d’exprimer la règle (« cette ressource appartient-elle à cet utilisateur » est une question de relation, pas de rôle), ReBAC Zanzibar pour les autorisations relationnelles fines décrit l’approche adaptée, et DAC, MAC, RBAC, ABAC ou ReBAC explique pourquoi un modèle fondé sur les seuls rôles ne sait pas y répondre.

Pour un cas voisin où le paramètre modifié n’est pas un identifiant d’objet mais une étendue de jeton, la confusion d’étendue OAuth montre la même erreur dans un protocole d’autorisation.

Ce qu’une équipe en fait

Vérifier l’appartenance à chaque accès, dans la requête elle-même. La forme la plus robuste consiste à ne jamais chercher une ressource par son seul identifiant : on la cherche par son identifiant et par son propriétaire. Une ressource qui n’appartient pas au demandeur devient alors introuvable, sans qu’aucun contrôle explicite ne puisse être oublié.

Centraliser la décision. Une fonction unique qui répond à « cet acteur peut-il accéder à cette ressource » permet de traiter tous les points d’entrée de la même façon et de la tester une fois pour toutes.

Employer des identifiants opaques, en sachant ce que cela apporte : du temps, pas de la sécurité. C’est une mesure de réduction du bruit (elle empêche l’énumération automatique), qui ne remplace jamais la vérification.

Écrire le test à deux comptes. Un utilisateur, un autre utilisateur, et une assertion par point d’entrée : c’est le test qui ferme cette classe, et il se génère automatiquement à partir de la liste des routes.

Sources

CWE-639: Authorization Bypass Through User-Controlled Key, MITRE, liste 4.20 : définition, parent CWE-863, termes alternatifs IDOR, BOLA et autorisation horizontale, note de mappage « Allowed ».
2025 CWE Top 25, MITRE : rang 24.

🐝 Ce qui arrive si on s’en passe

Une équipe qui croit corriger ce défaut en remplaçant les identifiants séquentiels par des identifiants aléatoires livre une application tout aussi vulnérable, avec un faux sentiment de sécurité et un ticket fermé. Le défaut subsiste pour quiconque obtient un identifiant par un autre moyen (un lien partagé, un journal, une pièce jointe, un ancien export), et surtout pour tout utilisateur légitime curieux, qui voit passer les identifiants de ses collègues dans l’usage normal du produit. Le coût particulier de cette classe est qu’elle produit des incidents de confidentialité à grande échelle et sans effraction : quelques milliers de requêtes parfaitement authentifiées suffisent à recopier la base, et rien ne les distingue d’une utilisation intensive du service. Quand la fuite est découverte, l’organisation doit expliquer à ses clients que leurs données ont été consultées par un compte autorisé, à travers des fonctions prévues à cet effet.

🦫 Explication de la marmotte 🍫

Quand on consulte une facture ou un dossier sur un site, l’adresse de la page contient souvent son numéro. Ce numéro sert au site à savoir quel document afficher.

Le défaut consiste à afficher le document demandé sans vérifier qu’il appartient bien à la personne qui le demande. Il suffit alors de modifier le numéro dans l’adresse pour consulter le dossier de quelqu’un d’autre. L’utilisateur était connecté, il avait le droit d’utiliser cette page, il a simplement changé un chiffre.

Ce défaut porte trois noms dans la profession (IDOR, BOLA, autorisation horizontale), et le numéro CWE-639 dans le catalogue. Il est l’un des plus fréquents, et l’un de ceux dont la correction est le plus souvent mal faite.

La mauvaise correction consiste à remplacer les numéros simples par de longues suites de caractères imprévisibles. Cela empêche de deviner les adresses au hasard, mais ne protège pas celui qui obtient une adresse par un autre moyen, ni surtout l’utilisateur légitime qui voit passer celles de ses collègues en se servant normalement du produit.

La bonne correction est ailleurs : à chaque demande, le site doit vérifier le lien entre le demandeur et le document. La façon la plus sûre de ne pas l’oublier consiste à ne jamais chercher un document par son seul numéro, mais toujours par son numéro et son propriétaire : un document qui n’appartient pas au demandeur devient alors tout simplement introuvable.

Pages voisines

CWE-639 : contournement d'autorisation par clé contrôlée par l'utilisateur (IDOR, BOLA)

Elle cite

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