Qu'est-ce qu'une référence directe non sécurisée à un objet ?
La référence directe non sécurisée à un objet (IDOR) est une vulnérabilité de contrôle d'accès qui permet aux attaquants d'accéder aux données d'autres utilisateurs en manipulant les identifiants d'objet dans les requêtes applicatives. Lorsque votre application expose une clé de base de données, un nom de fichier ou un identifiant d'enregistrement directement à l'utilisateur et ne vérifie pas si l'utilisateur demandeur possède cet objet, tout utilisateur authentifié peut consulter ou modifier les données d'un autre utilisateur simplement en changeant un chiffre dans une URL.
L'IDOR a été responsable de certaines des plus grandes expositions de données jamais enregistrées. En 2019, First American Financial Corporation a exposé plus de 800 millions d'images contenant des numéros de sécurité sociale et des coordonnées bancaires parce que son application permettait à quiconque de modifier un paramètre d'URL pour accéder à des documents appartenant à d'autres utilisateurs.
L'échec fondamental est simple : l'application confirme qu'un utilisateur est connecté (authentification) mais ne vérifie jamais s'il est autorisé à accéder à un enregistrement spécifique (autorisation). Votre application vérifie la serrure de la porte d'entrée mais laisse n'importe qui ouvrir tous les classeurs à l'intérieur.
L'IDOR correspond à CWE-639 : contournement de l'autorisation via une clé contrôlée par l'utilisateur. Dans le contexte des API, la même vulnérabilité est appelée Broken Object Level Authorization, ou BOLA, occupant la première place dans le OWASP API1 (API1:2023). Sa catégorie parente, Broken Access Control, est classée n°1 dans le OWASP Top 10 et conserve cette position dans l' édition 2025.
Avant d'examiner le fonctionnement technique, il est utile de comprendre les différentes formes que prend l'IDOR et sa place dans les cadres de vulnérabilité établis.
Types de référence directe non sécurisée à un objet
L'IDOR n'est pas une faille uniforme. Elle se manifeste différemment selon la relation de privilège impliquée et le type d'objet exposé.
IDOR horizontale
La forme la plus courante. Un utilisateur authentifié accède à des objets appartenant à un pair du même niveau de privilège, par exemple en modifiant /api/users/123/profile en /api/users/124/profile pour lire les données d'un autre compte. Il n'y a pas d'élévation de privilège : l'attaquant franchit simplement les frontières de compte au sein du même niveau.
IDOR verticale
L'attaquant accède à des objets nécessitant des privilèges supérieurs aux siens : accéder à un enregistrement administrateur, un endpoint de configuration restreint ou une fonction de gestion en manipulant un identifiant. L'IDOR verticale conduit souvent à une élévation complète de privilèges, comme dans le cas Honda eCommerce où un chercheur est passé d'un accès niveau concessionnaire à administrateur de la plateforme.
IDOR sur API (BOLA)
Dans les API REST et GraphQL, la même faille porte un nom distinct : Broken Object Level Authorization (BOLA). La nature sans état des API rend cette variante particulièrement répandue. Un seul resolver ou gestionnaire de route mal configuré peut exposer tous les enregistrements d'une collection à toute session authentifiée.
IDOR sur ressource statique
Les téléchargements de fichiers, exports et endpoints de rapports sont fréquemment oubliés lors des revues d'autorisation. Si une application sert un PDF à /reports/invoice_1042.pdf sans vérifier que l'utilisateur demandeur possède cette facture, la vulnérabilité est structurellement identique à une IDOR sur identifiant de base de données. Cette variante est courante dans les secteurs de la santé, de la finance et du juridique où les documents contiennent des données réglementées.
Chacune de ces formes correspond à une position distincte dans les cadres de gestion des vulnérabilités établis, ce qui complique la classification de l'IDOR.
Classification OWASP de la référence directe non sécurisée à un objet
L'IDOR apparaît dans trois cadres de vulnérabilité distincts, chacun reflétant une perspective organisationnelle différente sur la même défaillance sous-jacente.
| Cadre | Entrée | Nom | Position actuelle |
| OWASP Top 10 (2007–2013) | A4 | Insecure Direct Object References | Entrée autonome ; dépréciée comme entrée séparée |
| OWASP Top 10 (2021–2025) | A01 | Broken Access Control | #1 (regroupe 40 CWE, dont CWE-639) |
| OWASP API Security Top 10 | API1:2023 | Broken Object Level Authorization (BOLA) | #1 (Exploitabilité facile, Prévalence généralisée) |
| MITRE CWE | CWE-639 | Authorization Bypass Through User-Controlled Key | 2025 CWE Top 25 |
Positionnement dans l'OWASP Top 10
L'IDOR était une entrée autonome du Top 10 de 2007 à 2013. En 2017, OWASP l'a consolidée sous Broken Access Control, qui est passée en tête en 2021 et conserve cette position dans l'édition 2025, regroupant désormais 40 CWE sous cette catégorie.
OWASP API Security Top 10
BOLA, la déclinaison API de l'IDOR, occupe la position API1 depuis le lancement de l'API Security Top 10 en 2019. L'entrée API1:2023 attribue à BOLA la note la plus élevée pour l'exploitabilité (« Facile ») et la prévalence (« Généralisée »), ce qui explique pourquoi elle génère systématiquement plus de signalements que toute autre classe de vulnérabilité API.
Cartographie CWE
CWE-639 (Authorization Bypass Through User-Controlled Key) est la classification MITRE principale de l'IDOR. Sa catégorie parente est CWE-284 (Improper Access Control). L'enfant le plus spécifique pour les implémentations basées sur SQL est CWE-566 (Authorization Bypass Through User-Controlled SQL Primary Key). CWE-639 figure dans le CWE Top 25 de 2025.
Comprendre la taxonomie prépare à l'analyse du fonctionnement concret de l'exploitation.
Comment fonctionne la référence directe non sécurisée à un objet ?
L'IDOR exploite un écart fondamental entre ce que votre application authentifie et ce qu'elle autorise. Les étapes ci-dessous retracent comment un identifiant exposé devient une compromission massive de données.
Étape 1 : L'application expose une référence directe à un objet
Votre application génère une URL ou un paramètre API qui correspond directement à un objet interne :
La valeur 123 est la clé primaire de la base de données pour un enregistrement utilisateur, exposée directement dans le chemin de l'URL.
Étape 2 : L'attaquant modifie l'identifiant
Un attaquant remplace 123 par 124. Si l'application retourne les données du profil de l'utilisateur 124, la vulnérabilité est confirmée.
Étape 3 : Le serveur récupère l'objet sans vérification d'autorisation
La référence OWASP fournit un schéma de code vulnérable clair
Le décorateur @login_required confirme que l'utilisateur est connecté. Il ne vérifie pas si l'utilisateur 123 doit accéder au profil de l'utilisateur 124. Ajouter une ligne corrige la vulnérabilité :
Étape 4 : L'exploitation s'étend par énumération
Une fois le schéma confirmé, l'attaquant écrit un script pour itérer sur les valeurs d'identifiant possibles, transformant une seule vulnérabilité en compromission massive de données. Selon l'application, cette énumération peut être très rapide. La rapidité d'exploitation transforme une faille de contrôle d'accès en fuite de données à grande échelle.
Quatre surfaces d'attaque principales
| Surface | Exemple |
| Paramètres de chemin d'URL | /invoices/1042 changé en /invoices/1043 |
| Paramètres de chaîne de requête | ?order_id=7001 changé en ?order_id=7002 |
| Paramètres de fichier | ?file=report_user1.pdf changé en ?file=report_user2.pdf |
| Champs cachés dans le corps POST | user_id dans une soumission de formulaire changé pour l'identifiant d'un autre utilisateur |
Ces surfaces d'attaque existent en raison de causes structurelles profondes dans la conception et la construction des applications.
Causes de la référence directe non sécurisée à un objet
L'IDOR résulte de choix de conception structurelle et de conceptions erronées courantes chez les développeurs qui se cumulent dans les architectures applicatives.
Absence d'autorisation et requêtes non restreintes
La cause principale est l'utilisation d'entrées fournies par l'utilisateur pour récupérer des objets sans vérifier que l'utilisateur demandeur possède l'enregistrement. Cela se manifeste le plus souvent par des requêtes de base de données non restreintes : des applications qui interrogent la table complète des objets (Order.find(order_id)) au lieu de l'ensemble de données de l'utilisateur authentifié (current_user.orders.find(order_id)), exposant tous les enregistrements à toute session authentifiée.
Identifiants prévisibles et exposition directe de clés
MITRE CWE-639 l'identifie explicitement : les systèmes utilisant des identifiants d'enregistrement séquentiels ou facilement devinables permettent aux attaquants d'énumérer les données d'autres utilisateurs en incrémentant les valeurs. Exposer des clés primaires de base de données directement dans les URL ou les corps POST, en particulier des séquences d'entiers (1, 2, 3…), crée une surface d'attaque trivialement prévisible.
La fausse sécurité des UUID
La cheat sheet OWASP l'indique clairement : des identifiants complexes comme les GUID rendent la découverte de valeurs valides pratiquement impossible, mais les contrôles d'accès restent essentiels. Si des attaquants obtiennent des URL valides via des liens partagés ou des réponses applicatives, l'application doit toujours bloquer l'accès non autorisé.
Architecture API sans état
OWASP API1:2023 identifie une cause structurelle propre aux API : le serveur s'appuie sur des paramètres comme les identifiants d'objet envoyés par le client pour décider des objets à accéder. Les API REST et GraphQL sont structurellement prédisposées à l'IDOR sans logique d'autorisation explicite à chaque requête.
Lorsque ces causes ne sont pas traitées, les vulnérabilités qui en résultent ont un impact métier bien au-delà de la couche technique.
Impact et risque de la référence directe non sécurisée à un objet
L'impact de l'IDOR va de la divulgation de données à la prise de contrôle de compte complète, avec des conséquences réglementaires, financières et de sécurité.
Exposition massive de données
Parce que l'exploitation de l'IDOR est automatisable, un seul endpoint vulnérable peut exposer toute une base de données. L'IDOR de First American a exposé plus de 800 millions d'images. Optus a perdu des enregistrements clients via un endpoint API oublié avec contrôles d'accès défaillants.
Sanctions réglementaires et financières
Les violations IDOR déclenchent des mesures réglementaires sur plusieurs années. First American a reçu des sanctions de la part de la SEC et de la NYDFS. Optus a également subi d'importantes conséquences financières.
Prise de contrôle de compte et élévation de privilèges
L'IDOR ne se limite pas à la lecture de données. Dans un cas documenté sur la plateforme eCommerce de Honda, un chercheur a accédé à tous les enregistrements de concessionnaires en modifiant un seul identifiant, puis a escaladé jusqu'au rôle d'administrateur de la plateforme, réservé aux employés Honda.
Évaluations de sévérité OWASP
Le OWASP API Top 10 classe BOLA avec une exploitabilité « Facile » et une prévalence « Généralisée ». La combinaison d'une exploitation simple et d'une large prévalence explique sa position de n°1.
Ces évaluations de sévérité reflètent les méthodes utilisées par les attaquants pour exploiter l'IDOR à grande échelle.
Comment les attaquants exploitent la référence directe non sécurisée à un objet
L'exploitation de l'IDOR suit un processus structuré nécessitant peu de compétences techniques.
Substitution de paramètre
L'attaquant modifie un identifiant pour la valeur d'un autre utilisateur et observe la réponse. Changer /api/users/123/profile en /api/users/124/profile et recevoir une réponse 200 OK au lieu de 403 Forbidden confirme la vulnérabilité.
Énumération automatisée
Une fois confirmée, les attaquants automatisent l'exploitation avec le module Intruder de Burp Suite, OWASP ZAP ou des scripts personnalisés pour itérer sur toutes les valeurs d'identifiant possibles. La documentation OWASP API décrit comment un simple script manipulant les identifiants dans une URL donne accès à des milliers d'enregistrements.
Exploitation en chaîne
Les attaquants combinent l'IDOR à d'autres vulnérabilités. Le cas Honda eCommerce illustre un accès horizontal aux données combiné à une élévation verticale de privilèges. La plateforme McHire de McDonald's a combiné une IDOR à des identifiants par défaut, aggravant l'exposition.
Accès horizontal et vertical
Le guide OWASP sur le contrôle d'accès clarifie la distinction. L'IDOR permet le plus souvent une élévation horizontale de privilèges : l'utilisateur A accède aux données de l'utilisateur B au même niveau de privilège. Plus rarement, l'IDOR permet une élévation verticale : un utilisateur standard obtient un accès administrateur.
La simplicité de ces techniques signifie que pratiquement toute application gérant des données utilisateur peut devenir une cible.
Qui est concerné par la référence directe non sécurisée à un objet ?
L'IDOR affecte toute application utilisant des identifiants contrôlables par l'utilisateur pour accéder à des objets sans vérification d'autorisation à chaque requête.
Architectures applicatives à haut risque
Le risque IDOR est amplifié par certains schémas structurels qui exposent plus largement les références d'objet ou rendent les contrôles d'autorisation plus faciles à contourner.
- API REST avec des schémas d'URL basés sur les ressources. Toute API suivant la convention
/resource/{id}présente une exposition structurelle à l'IDOR par conception. - API GraphQL. L'accès aux objets via des arguments crée la même vulnérabilité lorsque les resolvers omettent les vérifications de propriété.
- Applications SaaS multi-locataires. Un utilisateur d'un tenant manipule des identifiants pour accéder aux données d'un autre tenant.
- Backends API IoT et mobiles. Des flux d'authentification complexes et une gestion limitée de l'état côté serveur augmentent l'exposition BOLA.
- Plateformes e-commerce. Les identifiants de commande, de facture et de compte client sont des cibles de grande valeur.
Ce qui unit toutes ces architectures, c'est que l'accès aux objets est piloté par des identifiants contrôlés côté client, sans vérification de propriété côté serveur avant le retour des données.
Secteurs à haut risque
Les secteurs les plus exposés sont ceux où les références d'objet correspondent directement à des enregistrements sensibles, des données réglementées ou des systèmes physiques.
- Santé : CVE-2024-28320 (Hospital Management System, CVSS 7.6) a permis la lecture et la modification de données patient.
- Services financiers : Les plateformes de paiement et sociétés de titres font face à la fois à l'exposition de données et au risque réglementaire.
- Gouvernement : Selon HackerOne, les programmes gouvernementaux signalent l'IDOR comme un problème récurrent.
- Automobile : Les cas Pandora/Viper et CVE-2025-11690 confirment le risque réel pour les systèmes de véhicules.
Des compromissions documentées dans ces secteurs illustrent les conséquences concrètes de l'absence de correction de l'IDOR.
Exemples concrets de référence directe non sécurisée à un objet
Les cas suivants montrent comment l'IDOR s'est manifestée dans différents secteurs et types d'applications. Chaque incident remonte à la même défaillance racine : des identifiants fournis par l'utilisateur atteignant un serveur qui ne vérifie jamais si le demandeur possède l'objet retourné.
First American Financial Corporation (2019)
L'application EaglePro de First American permettait à tout utilisateur de modifier un paramètre d'URL pour accéder à des documents d'entiercement et de titres appartenant à d'autres utilisateurs. La vulnérabilité, introduite en 2014, a persisté cinq ans. Plus de 800 millions d'images ont été exposées, dont des numéros de sécurité sociale et des documents de paiement hypothécaire. Les sanctions réglementaires sont documentées dans le dossier SEC et le dossier NYDFS. La CISA, la NSA et l'Australian Signals Directorate ont cité ce cas dans leur avis conjoint sur l'IDOR.
Fuite de données Optus (2022)
Une erreur de codage de 2018 a cassé les contrôles d'accès sur un endpoint API d'Optus. Optus a corrigé l'erreur sur son domaine principal en 2021 mais a laissé un domaine oublié, exposé sur Internet, non corrigé. En septembre 2022, un attaquant a exploité ce contrôle d'accès défaillant pour exfiltrer des enregistrements clients, dont des numéros d'identité valides. L'Australian Communications and Media Authority (ACMA) a confirmé que l'attaque « n'était pas très sophistiquée » et a été réalisée par « un simple processus d'essais et d'erreurs ». Il s'agit de la plus grande fuite de données en Australie.
Chatbot McHire de McDonald's (2025)
Les chercheurs en sécurité Ian Carroll et Sam Curry ont découvert une IDOR dans l'API du chatbot Paradox.ai McHire utilisé par McDonald's. En décrémentant un entier lead_id dans l'endpoint interne /api/lead/cem-xhr, ils ont récupéré des transcriptions de chat complètes, des coordonnées et des jetons de session d'autres candidats sans aucune vérification d'autorisation. Leur propre lead_id était 64 185 742, indiquant l'ampleur des enregistrements potentiellement accessibles. La vulnérabilité a été divulguée le 30 juin 2025 et corrigée le jour même.
Pandora et Viper Smart Car Alarms (2019)
Pen Test Partners a trouvé des vulnérabilités IDOR dans les API d'alarmes de voiture connectées permettant la prise de contrôle complète de comptes sur des flottes de véhicules. Les attaquants pouvaient changer les mots de passe ou adresses e-mail des comptes, obtenant un contrôle physique sur les véhicules. Les chercheurs estiment qu'environ trois millions de véhicules haut de gamme étaient exposés avant la correction rapide des failles par les fournisseurs.
Signal bug bounty
L'IDOR est une découverte à forte valeur sur les plateformes de bug bounty. Un rapport PayPal a obtenu une prime notable sur HackerOne, et les données HackerOne montrent que l'IDOR reste une classe de vulnérabilité récurrente.
Ces incidents retracent plus d'une décennie de présence de l'IDOR dans les cadres de vulnérabilité majeurs et les compromissions réelles.
Chronologie et historique de la référence directe non sécurisée à un objet
L'IDOR fait partie du paysage formel de la sécurité depuis près de vingt ans. La chronologie ci-dessous retrace son évolution d'une catégorie autonome à un concept fondamental intégré dans plusieurs cadres, et son expansion continue vers de nouvelles infrastructures comme les API, l'IoT et l'IA.
| Période | Événement marquant |
| 2007 | OWASP introduit le terme « IDOR » dans le Top Ten comme catégorie autonome à A4. |
| 2013-2014 | Dernière année en tant que catégorie autonome OWASP (A4). Introduction du défaut IDOR chez First American |
| 2017 | L'IDOR est consolidée dans Broken Access Control à A5. |
| 2019 | L'OWASP API Security Top 10 introduit BOLA en API1. Divulgation First American. Exposition Pandora/Viper documentée. |
| 2021 | Broken Access Control en n°1 dans l'OWASP Top 10. |
| 2022 | Fuite Optus, plus grande fuite de données australienne. |
| 2023 | CISA/NSA/ACSC publient l'avis conjoint AA23-208A sur l'IDOR. BOLA conservé en API1:2023. |
| 2025 | Broken Access Control reste n°1, regroupant 40 CWE. CWE-639 listé dans le CWE Top 25 de 2025. IDOR McHire McDonald's divulguée par Ian Carroll et Sam Curry. |
| 2024-2026 | L'IDOR s'étend à l'infrastructure IA/LLM (CVE-2025-4962), télématique véhicule (CVE-2025-11690), et IAM d'entreprise (CVE-2024-56404). HackerOne confirme la hausse des signalements IDOR alors que XSS et SQLi diminuent. |
Avec la persistance de l'IDOR sur près de deux décennies de suivi des vulnérabilités, il vous faut des méthodes fiables pour la détecter dans vos propres applications.
Comment détecter la référence directe non sécurisée à un objet
L'IDOR est difficile à détecter uniquement avec des outils car elle nécessite une analyse de la propriété des objets et de la logique métier, et non un simple appariement de codes de réponse.
Pentest manuel (requis)
Le OWASP WSTG définit la procédure de test :
- Cartographier tous les emplacements où une entrée utilisateur référence directement des objets.
- Modifier la valeur du paramètre utilisé pour référencer les objets.
- Évaluer si vous pouvez récupérer des objets appartenant à d'autres utilisateurs ou contourner l'autorisation.
- Tester différents verbes HTTP et schémas d'accès en masse.
Le test manuel est la seule méthode qui raisonne sur l'intention d'autorisation plutôt que sur la simple manipulation de paramètres. Aucun scanner ne peut remplacer un testeur qui comprend ce à quoi chaque rôle utilisateur doit ou non avoir accès.
Outils de test de sécurité applicative
Les outils DAST comme OWASP ZAP et Burp Suite peuvent détecter l'IDOR lorsqu'ils sont configurés avec des comptes de test multi-utilisateurs et des mappages d'identifiants inter-utilisateurs. Les configurations par défaut des scanners ne détecteront pas l'IDOR. Les outils SAST peuvent signaler les endpoints dépourvus d'appels de fonction d'autorisation mais ne peuvent pas vérifier la correction sémantique de la logique d'autorisation à l'exécution.
Surveillance comportementale à l'exécution
C'est le seul contrôle en production qui peut réellement détecter l'IDOR en production. Recherchez ces signaux :
- Requêtes séquentielles ou en schéma d'énumération vers des endpoints de référence d'objet depuis une même session
- Requêtes authentifiées retournant 200 OK pour des identifiants d'objet n'appartenant pas à l'utilisateur demandeur
- Requêtes volumineuses de référence d'objet sur plusieurs comptes utilisateur
Contrairement aux tests pré-déploiement, la surveillance comportementale fonctionne en continu en production, là où l'exploitation réelle a lieu. C'est le seul contrôle capable de détecter l'abus actif de l'IDOR sur des données réelles.
Revue de code sécurisée
Selon la cheat sheet sur l'autorisation, la revue de code doit vérifier que la permission est validée à chaque requête et que le contrôle d'accès est implémenté globalement plutôt que par méthode. Portez une attention particulière aux endpoints acceptant des identifiants fournis par l'utilisateur et suivez le chemin du code depuis la réception du paramètre jusqu'à la requête base de données et la réponse. Tout chemin qui récupère un objet sans restreindre la requête aux permissions de l'utilisateur authentifié représente un risque IDOR confirmé.
Détecter l'IDOR n'est que la première étape. La prévenir nécessite des contrôles intégrés tout au long du cycle de développement et de déploiement.
Comment prévenir la référence directe non sécurisée à un objet
La prévention nécessite une approche en couches couvrant la conception, le développement, les tests et la surveillance à l'exécution.
Phase de conception : modéliser l'autorisation dans chaque fonctionnalité
Intégrez le contrôle d'accès défaillant à votre analyse de la surface d'attaque lors de la conception fonctionnelle. Définissez des fonctions d'autorisation explicites (canAccess, isOwner) avant d'écrire du code.
Phase de développement : appliquer l'autorisation côté serveur à chaque accès objet
La cheat sheet IDOR recommande les contrôles suivants :
- Implémenter des contrôles d'accès pour chaque objet qu'un utilisateur tente d'accéder. Déterminez l'utilisateur authentifié à partir de la session, pas d'identifiants fournis par le client. Appliquez les contrôles via un middleware centralisé plutôt que par logique individuelle.
- Restreindre les requêtes base de données à l'ensemble accessible de l'utilisateur authentifié :
Utiliser des mappages de référence indirecte qui traduisent des valeurs externes obscurcies en identifiants internes de base de données, combinés à des contrôles d'autorisation.
Adopter des UUID ou valeurs aléatoires longues comme identifiants publics. Il s'agit d'une défense en profondeur, pas d'un contrôle principal.
Éviter le chiffrement des identifiants. La cheat sheet OWASP indique que cela « peut être difficile à mettre en œuvre de façon sécurisée ».
- Appliquer l'autorisation sur les ressources statiques, une surface souvent négligée selon la cheat sheet sur l'autorisation.
Ces contrôles sont efficaces car ils imposent la propriété au niveau des données plutôt que de faire confiance aux valeurs fournies par le client. Un attaquant qui manipule un paramètre rencontre un contrôle d'autorisation plutôt qu'une requête réussie.
Phase de test : tests d'autorisation multi-utilisateurs
Effectuez des scans DAST avec des configurations multi-utilisateurs testant l'accès inter-comptes. Ajoutez des règles SAST signalant les endpoints sans appel de fonction d'autorisation. Priorisez le pentest manuel pour les IDOR de logique métier.
Phase d'exécution : surveillance comportementale des API
Déployez une surveillance comportementale qui établit une base de référence des schémas d'accès API normaux et signale les accès objets anormaux. La technologie Storyline de SentinelOne peut reconstituer la séquence complète des interactions API et le contexte d'identité autour des accès suspects, fournissant à votre équipe la chronologie forensique nécessaire pour confirmer ou infirmer une exploitation IDOR.
La mise en œuvre efficace de ces contrôles nécessite la bonne combinaison d'outils de test de sécurité applicative et de surveillance à l'exécution.
Outils de détection et de prévention
Aucun outil unique ne couvre complètement l'IDOR. Une couverture efficace nécessite une combinaison en couches de scans à la conception, de surveillance à l'exécution et de validation manuelle tout au long du cycle de vie applicatif. Les outils ci-dessous couvrent différentes phases, chacun avec une couverture et des limites distinctes.
Outils de test de sécurité applicative
| Type d'outil | Capacité | Couverture IDOR | Limite |
| DAST (OWASP ZAP, Burp Suite) | Teste les applications en cours via HTTP/S | Détecte l'IDOR avec des configurations multi-utilisateurs | Nécessite une configuration manuelle de scénarios de test inter-comptes |
| SAST (SonarQube, Checkmarx) | Analyse de code source en boîte blanche | Signale les schémas d'absence d'appel d'autorisation | Ne peut pas vérifier la correction sémantique de la logique d'autorisation |
| IAST (Contrast Security) | Agent embarqué lors des tests QA | Contexte comportemental à l'exécution avec moins de faux positifs | Nécessite des environnements de test instrumentés |
| Pentest manuel | Logique métier, scénarios multi-utilisateurs | Seule méthode fiable pour les IDOR complexes | Chronophage, nécessite des testeurs qualifiés |
Sécurité API et surveillance comportementale
Les outils de surveillance comportementale API établissent des bases de référence des schémas d'accès normaux et signalent les anomalies. Ce sont les seuls contrôles à l'exécution capables de détecter réellement l'exploitation IDOR en production, car les requêtes IDOR sont syntaxiquement identiques au trafic légitime.
Vulnérabilités associées
L'IDOR appartient à la famille plus large du Broken Access Control. Comprendre ses liens avec d'autres types de vulnérabilités vous aide à prioriser la remédiation.
- Broken Object Level Authorization (BOLA), API1:2023. L'IDOR et BOLA correspondent à CWE-639. BOLA est la déclinaison API de la même défaillance sous-jacente.
- Broken Function Level Authorization (BFLA), API5:2023 / CWE-285. Alors que l'IDOR cible les objets de données (quels enregistrements vous pouvez accéder), BFLA cible les fonctions API (quelles opérations vous pouvez effectuer), permettant principalement l'élévation verticale de privilèges.
- Forced Browsing (CWE-425). Contourne la navigation et les contrôles de page pour accéder directement à des pages restreintes, listé comme exemple concret de Broken Access Control.
- Contournement d'autorisation via clé primaire SQL (CWE-566). Enfant direct de CWE-639, c'est le CWE le plus spécifique pour les implémentations IDOR basées sur SQL.
- Élévation verticale de privilèges (CWE-269 / CWE-285). L'IDOR peut se chaîner en élévation de privilèges lorsqu'un attaquant modifie un identifiant pour accéder à des fonctions administratives, comme démontré dans le cas Honda eCommerce.
Plusieurs CVE spécifiques illustrent comment ces schémas de vulnérabilité associés apparaissent dans les systèmes en production.
CVEs associés
| ID CVE | Description | Gravité | Produit affecté | Année |
| CWE-639 IDOR dans les modules API tab-doc de Tableau Server : un attaquant sur le réseau adjacent manipule des clés contrôlées par l'utilisateur pour contourner l'autorisation et accéder aux clusters de base de données de production | ÉLEVÉE | Salesforce Tableau Server (<2025.1.3) | 2025 | |
| CWE-639 IDOR dans la commande tabdoc set-initial-sql de Tableau Server : des utilisateurs authentifiés à faible privilège manipulent des paramètres contrôlés par l'utilisateur pour accéder aux clusters de base de données de production | ÉLEVÉE | Salesforce Tableau Server (<2025.1.3) | 2025 | |
| CWE-639 IDOR dans la gestion des ressources thread de Chainlit : des utilisateurs authentifiés fournissent l'identifiant de thread d'un autre utilisateur pour accéder à des données de conversation sans vérification de propriété | MOYENNE | Chainlit | 2025 | |
| CWE-639 IDOR dans le plugin WordPress Five Star Restaurant Reservations : des attaquants non authentifiés manipulent des identifiants de réservation pour accéder, modifier ou supprimer des enregistrements d'autres utilisateurs | MOYENNE | Five Star Restaurant Reservations WP plugin (≤2.7.8) | 2025 | |
| IDOR dans One Identity Identity Manager permettant l'élévation de privilèges sur installations on-premise : un attaquant manipule des références d'objet pour obtenir des permissions supérieures à son rôle attribué | CRITIQUE | One Identity Identity Manager 9.x (<9.3) | 2024 | |
| IDOR non authentifiée dans l'outil SO Planning : lorsque la vue publique est activée, un attaquant accède à la base de données complète en demandant directement l'endpoint d'export, la téléchargeant au format CSV | CRITIQUE | SO Planning (<1.52.02) | 2024 | |
| IDOR non authentifiée dans WooCommerce Stripe Payment Gateway : absence de vérification de propriété de commande expose le nom, l'e-mail et l'adresse de facturation de toute commande à des utilisateurs non authentifiés sur plus de 900 000 installations actives | ÉLEVÉE | WooCommerce Stripe Payment Gateway WP plugin (≤7.4.0) | 2023 | |
| CWE-639 IDOR dans la plateforme d'imagerie médicale ExtremePacs Extreme XDS : manipulation de clé contrôlée par l'utilisateur permettant d'accéder à des images d'autres patients sans autorisation | ÉLEVÉE | ExtremePacs Extreme XDS (<3914) | 2023 | |
| IDOR dans le serveur backend partagé de stalkerware exposant SMS, historiques d'appels, photos et géolocalisations de centaines de milliers d'appareils ; cité par nom dans l'avis CISA/NSA/ACSC AA23-208A | ÉLEVÉE | 1byte / Plusieurs applications stalkerware | 2022 | |
| IDOR dans la fonction de réinitialisation de mot de passe du Telos Alliance Omnia MPX Node : un attaquant fournit l'identifiant de compte de n'importe quel utilisateur pour réinitialiser son mot de passe, permettant la prise de contrôle complète de compte, y compris administrateur | ÉLEVÉE | Telos Alliance Omnia MPX Node (1.0.0–1.4.x) | 2022 |
Une cybersécurité alimentée par l'IA
Améliorez votre posture de sécurité grâce à la détection en temps réel, à une réponse à la vitesse de la machine et à une visibilité totale de l'ensemble de votre environnement numérique.
Obtenir une démonstrationConclusion
La référence directe non sécurisée à un objet demeure l'une des failles de sécurité web les plus exploitées car elle compromet l'autorisation au niveau objet, et non simplement la gestion des entrées. Si votre application fait confiance aux identifiants fournis par l'utilisateur sans vérifier la propriété, un simple changement d'URL peut entraîner une exposition massive de données.
Vous réduisez ce risque en appliquant l'autorisation à chaque accès objet, en testant sur plusieurs contextes utilisateurs et en surveillant les abus en production.
FAQ
L'IDOR est un défaut d'application de la propriété des enregistrements. Si votre serveur ne vérifie pas qu'un utilisateur peut accéder à un objet spécifique, la modification d'un nom de fichier, d'un numéro de commande ou d'un identifiant de profil peut exposer ou altérer les données d'autrui. En pratique, l'IDOR est d'abord un problème d'autorisation, puis un problème de manipulation de paramètres.
Oui. Les anciens documents OWASP peuvent l'appeler IDOR, tandis que les recommandations récentes l'incluent dans Broken Access Control. Les équipes axées sur les API appellent souvent cette même faille BOLA.
Différents termes désignent la même cause racine : l'absence d'autorisation au niveau des objets.
Oui. Un attaquant a généralement seulement besoin d'un point de terminaison accessible et d'un moyen valide d'envoyer des requêtes. Il n'a en général pas besoin d'exécution de code ni de livraison de malware.
Une fois qu'un schéma de référence d'objet fonctionne, l'exploitation peut s'étendre via des requêtes scriptées, ce qui explique pourquoi les domaines oubliés, les anciennes versions d'API et les backends mobiles exposés sont particulièrement à risque.
Les applications sont les plus vulnérables lorsque la recherche d'objet dépend des entrées du client. Le risque augmente dans les systèmes qui exposent de nombreuses références d'objets, partagent l'infrastructure entre plusieurs locataires ou reposent sur des API sans état qui font confiance de façon répétée aux identifiants envoyés par le client. Les opérations à fort impact incluent la récupération, la mise à jour, l'exportation ou la suppression d'enregistrements liés à un utilisateur.
Les attaquants commencent généralement là où l'application révèle la façon dont elle nomme les objets : un identifiant visible dans une URL, un champ de formulaire caché, un corps JSON ou une réponse d'API. Ils échangent ensuite les valeurs, comparent les réponses et testent différentes méthodes ou contextes de compte.
Même de petites différences dans les codes d'état, la taille des réponses ou les champs retournés peuvent confirmer un accès exploitable à un objet.
Les premiers signes sont généralement comportementaux. Surveillez une identité authentifiée qui demande de nombreux identifiants d'objet, franchit les limites attendues de compte ou de locataire, ou accède à des enregistrements dans un ordre qui ne correspond pas au comportement utilisateur normal.
Comme l'IDOR se dissimule souvent dans un trafic HTTP par ailleurs valide, le contexte compte plus que la syntaxe.
Sa gravité provient autant de l'échelle et de la fiabilité que du CVSS brut. De nombreuses vulnérabilités nécessitent des chaînes d'exploitation fragiles ; l'IDOR fonctionne souvent avec le comportement normal de l'application dès lors que la vérification de propriété est absente.
Elle peut aller d'une fuite de données limitée à une prise de contrôle de compte ou une élévation de privilèges, selon l'objet exposé.
Parfois. Si l'objet exposé contrôle la réinitialisation de mot de passe, les paramètres administratifs, les limites de locataire ou les actions de workflow, l'IDOR peut devenir la première étape d'une prise de contrôle plus large.
La fonction métier de l'objet détermine si la faille reste locale à un enregistrement ou s'étend à l'ensemble de la plateforme.
Pas par défaut. Les outils peuvent trouver des entrées et rejouer des requêtes, mais l'IDOR nécessite de comprendre qui doit posséder quel objet et comment les rôles diffèrent selon les sessions.
L'approche la plus efficace combine l'automatisation avec des jeux de données multi-utilisateurs préparés et une validation manuelle. En production, la surveillance comportementale est plus réaliste que de s'appuyer uniquement sur des scanners.
Les secteurs les plus à risque sont ceux où les références d'objet correspondent directement à des enregistrements sensibles, des données réglementées ou des effets dans le monde physique. En pratique, cela inclut les dossiers de santé, les documents financiers, les données gouvernementales, les systèmes automobiles et les actifs de gestion d'identité.
Dans ces environnements, chaque accès non autorisé à un objet peut entraîner des conséquences majeures en matière de confidentialité, de conformité, de fraude ou de sécurité.
