Glossaire
IDOR (Insecure Direct Object Reference)
Vulnérabilité de contrôle d'accès où un utilisateur peut accéder à des ressources d'autres utilisateurs en modifiant un identifiant dans la requête (ID numérique, UUID). Les IDOR sont fréquentes dans les API REST et permettent de consulter, modifier ou supprimer les données d'autrui. C'est l'une des failles les plus trouvées lors des audits de PME.
Comment un IDOR s'exploite dans un SaaS RH
Dans un logiciel RH, paie ou recrutement, presque chaque ressource est rattachée à un identifiant : fiche salarié, bulletin de paie, contrat, candidature. Un IDOR apparaît quand l'API vérifie que l'utilisateur est connecté, mais pas que la ressource demandée lui appartient. Il suffit alors de remplacer /api/employees/1842 par /api/employees/1843 pour lire la fiche d'un salarié d'une autre entreprise cliente. Les identifiants séquentiels aggravent le problème : un script peut énumérer toute la base en quelques minutes. Les UUID réduisent l'énumération mais ne corrigent pas la faille : si un UUID fuite (email, export, log), la ressource reste accessible sans contrôle.
Exemple concret côté paie
Cas typique rencontré en audit : un endpoint de téléchargement de bulletins du type /api/payslips/download?id=98123 signé pour l'utilisateur courant, mais dont l'identifiant n'est pas relié au compte. Résultat : n'importe quel salarié authentifié peut télécharger les bulletins de paie de toute la plateforme, y compris ceux des autres entreprises clientes. Au regard du RGPD, il s'agit d'une violation de données à caractère personnel : salaires, adresses, numéros de sécurité sociale.
Comment CleanIssue détecte les IDOR
Lors d'une revue externe, nous testons systématiquement les endpoints qui manipulent des identifiants : incrémentation d'ID, échange d'identifiants entre deux comptes de test, rejeu de requêtes d'un tenant vers un autre. Chaque constat est documenté avec une preuve reproductible et une évaluation de l'impact métier (quelles données salariés sont réellement exposées). C'est l'une des failles les plus fréquentes dans nos audits de SaaS RH — et l'une des plus simples à corriger : un contrôle d'appartenance systématique côté serveur.
Questions fréquentes
Quelle différence entre IDOR et BOLA ?
BOLA (Broken Object Level Authorization) est le nom donné au même problème dans le contexte des API — c'est la vulnérabilité n°1 du top 10 API d'OWASP. IDOR est le terme historique côté applications web. En pratique, les deux désignent un contrôle d'autorisation manquant au niveau de l'objet.
Les UUID protègent-ils contre les IDOR ?
Non. Les UUID rendent l'énumération plus difficile, mais ne remplacent pas un contrôle d'accès. Si un UUID est exposé dans une URL partagée, un export ou un log, la ressource reste accessible à quiconque le possède. La seule correction fiable est la vérification d'appartenance côté serveur à chaque requête.
Un IDOR dans un logiciel RH est-il une violation RGPD ?
Si la faille a été exploitée et que des données personnelles (bulletins, contrats, coordonnées) ont été consultées par un tiers non autorisé, il s'agit d'une violation de données au sens de l'article 33 du RGPD, potentiellement notifiable à la CNIL sous 72 heures. Détecter et corriger ces failles avant incident relève de l'obligation de sécurité de l'article 32.