Le nom anglais, Insecure Direct Object Reference, se traduit par « référence directe non sécurisée à un objet ». L’« objet » peut être une commande, une facture, un profil, un fichier ou un message ; la « référence » est l’identifiant qui le désigne dans l’URL, un formulaire ou une requête d’API. Selon l’OWASP, la faille vient d’un contrôle d’accès manquant : l’application vérifie que l’utilisateur est connecté, mais pas qu’il a le droit de consulter cet objet-là.
Comment fonctionne une faille IDOR
L’attaque ne demande aucun outil particulier. Un client connecté consulte sa facture à l’adresse /mon-compte/facture/?id=1057. Il remplace 1057 par 1042, et le site affiche la facture d’un autre client, avec son nom et son adresse. Le même scénario se retrouve dans une route d’API (/wp-json/boutique/v1/commandes/1042), un téléchargement de pièce jointe ou une action de suppression.
C’est la forme la plus courante d’élévation de privilèges horizontale : l’attaquant ne monte pas en grade, il accède aux données d’un utilisateur de même niveau. Le MITRE la classe sous CWE-639 (« contournement d’autorisation par une clé contrôlée par l’utilisateur ») et l’OWASP API Security parle de BOLA (Broken Object Level Authorization). Dans le Top 10 de l’OWASP, elle relève de la catégorie A01, contrôle d’accès défaillant, qui cite explicitement la consultation ou la modification du compte d’un autre grâce à son identifiant.
Comment s’en protéger
- Vérifier chaque objet : pour chaque requête, comparer le propriétaire de l’objet demandé avec l’utilisateur connecté, côté serveur.
- Ne chercher que dans ce qui appartient à l’utilisateur : une requête du type « les commandes de l’utilisateur courant dont l’identifiant est X » ne renverra jamais celle d’un autre.
- Éviter d’exposer l’identifiant quand il n’est pas nécessaire : pour « mon profil », l’utilisateur se déduit de la session.
- Ne pas compter sur des identifiants aléatoires : ils rendent la devinette plus difficile, mais l’OWASP rappelle qu’ils ne remplacent pas le contrôle d’accès.
Pour WordPress
WordPress propose des capacités « méta » qui vérifient le droit sur un objet précis. current_user_can( 'edit_post', $post_id ) ne demande pas seulement « cet utilisateur peut-il modifier des articles ? », mais « peut-il modifier cet article ? », en tenant compte de l’auteur et du statut :
$post_id = absint( $_POST['post_id'] ?? 0 );
if ( ! current_user_can( 'edit_post', $post_id ) ) {
wp_send_json_error( null, 403 );
}Pour les données propres à une extension (commandes, réservations, fichiers privés), il faut écrire ce contrôle soi-même, par exemple en comparant l’auteur enregistré avec get_current_user_id(). Dans l’API REST, ce contrôle a sa place dans le permission_callback de la route. Deux confusions reviennent souvent : un nonce valide prouve que la requête vient bien du site et protège contre la falsification de requête, pas que l’utilisateur a le droit d’accéder à l’objet ; et masquer un lien dans l’interface n’empêche pas d’appeler l’URL directement.
Pour tester une extension, créez deux comptes de même rôle et essayez d’ouvrir avec l’un les objets de l’autre. Les failles de contrôle d’accès figurent parmi les plus fréquentes dans les extensions, comme le montrent les statistiques des failles d’extensions ; notre article sur l’API REST aide à repérer ce qui est exposé publiquement sur votre site, et celui sur les rôles et capacités à limiter ce que chaque compte peut atteindre.