Insecure Direct Object Reference

hacking

Définition

L'IDOR (Insecure Direct Object Reference) est une vulnérabilité de contrôle d'accès dans laquelle une application web expose directement des références à des objets internes (IDs de base de données, noms de fichiers, clés API) dans les URLs, corps de requêtes, ou paramètres, sans vérifier que l'utilisateur authentifié est autorisé à accéder à l'objet référencé. Cette vulnérabilité permet l'accès horizontal non autorisé entre comptes utilisateurs (OWASP Top 10 - A01:2021). Des exemples typiques d'IDOR : une URL comme /api/users/12345/documents où le changer en /api/users/12346/documents donne accès aux documents d'un autre utilisateur ; un paramètre de formulaire order_id=1234 modifiable pour afficher la commande d'un autre client ; un endpoint /download?file=invoice_12345.pdf permettant de télécharger n'importe quelle facture en changeant l'ID. L'IDOR devient critique quand il affecte des données sensibles (informations médicales, financières, personnelles) ou des actions privilégiées (paiements, suppressions, modifications). Les IDOR peuvent également permettre une escalade verticale (accéder à des ressources d'un administrateur) si les IDs d'admin sont prévisibles. Les techniques de contournement incluent : tester différents encodages de l'ID (Base64, hash MD5, GUID), modifier des paramètres cachés dans les formulaires, intercepter et modifier les requêtes API mobile (souvent moins testées que le web), et tester des endpoints undocumentés découverts via fuzzing ou décompilation d'app mobile. Des bugs IDOR ont été parmi les plus rémunérateurs en bug bounty : des IDOR sur des APIs de données médicales ou financières ont rapporté 50 000$+ sur des programmes comme HackerOne.

Fonctionnement

Détection manuelle avec Burp Suite : naviguer vers un profil utilisateur (/user/12345), envoyer la requête au Repeater, changer l'ID (12345 → 12346, 1, 0, -1, ADMIN), observer la réponse. Automatisation avec Burp Intruder sur les paramètres d'ID. Test API : curl -H 'Authorization: Bearer TOKEN_USER_A' https://api.target.com/v1/users/USER_B_ID/profile. Si la réponse retourne le profil de l'utilisateur B, c'est un IDOR. Tester également les méthodes HTTP alternatives (GET vs DELETE vs PATCH sur le même endpoint).

Exploitation offensive

Les IDORs sont parmi les vulnérabilités les plus fréquentes et les plus impactantes dans les applications web modernes, particulièrement dans les APIs REST et mobiles où les contrôles d'autorisation sont souvent insuffisants. Un IDOR dans une API de données médicales peut exposer des millions de dossiers patients. Les programmes de bug bounty paient le plus pour les IDORs sur des données sensibles ou des actions critiques.

Détection et mitigation

Implémenter une vérification systématique des autorisations côté serveur pour chaque accès à un objet : l'ID seul ne suffit pas — vérifier que l'utilisateur authentifié est propriétaire ou a les droits sur l'objet. Utiliser des références indirectes (tokens opaques dérivés de l'ID + contexte utilisateur) plutôt que des IDs séquentiels. Des tests automatisés d'autorisation (OWASP ZAP avec des règles d'autorisation) intégrés à la CI/CD détectent les régressions IDOR.

Articles liés

Expert en cybersécurité offensive et intelligence artificielle. Pentest, audit et développement IA sur-mesure.

Services

Ressources

Projets & Outils

Contact

Nous contacter

Mentions légales Confidentialité Politique éditoriale Plan du site ⭐ Source préférée

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis