Référence directe non sécurisée à un objet (IDOR)
IDOR · insecure direct object reference · BOLA · broken object level authorization · contrôle d’accès défaillant
Faille de contrôle d’accès où l’application donne accès à une ressource (facture, dossier, compte) à partir de son seul identifiant, sans vérifier que l’utilisateur a le droit de la consulter.
En pratique
Si l’adresse de votre facture se termine par un numéro, que se passe-t-il quand on change ce numéro ? Dans une application vulnérable, on voit la facture d’un autre client. La faille est simple, difficile à détecter automatiquement (un outil ne sait pas ce que chaque utilisateur a le droit de voir) et exploitable en masse par un script. Elle relève du contrôle d’accès défaillant, premier risque de l’OWASP Top 10:2025 (A01) ; le Top 10 de la sécurité des API la nomme BOLA.
En juillet 2023, les agences australienne et américaines (ACSC, CISA, NSA) ont publié un avis commun sur les IDOR : des failles courantes, difficiles à prévenir hors du processus de développement, qui ont déjà conduit à des fuites touchant des millions d’utilisateurs.
Comment s’en protéger
- Vérifier côté serveur, à chaque requête, que l’utilisateur a le droit d’accéder à l’objet demandé.
- Centraliser les règles d’autorisation au lieu de les répéter dans chaque page.
- Préférer des identifiants aléatoires (UUID) aux numéros qui se suivent, en complément du contrôle.
- Tester systématiquement avec deux comptes différents lors des recettes et des tests d’intrusion.
