IDOR (Insecure Direct Object Reference)

L'IDOR (Insecure Direct Object Reference) est une vulnérabilité d'autorisation où une application expose un identifiant d'objet (ID dans l'URL, paramètre POST, header) et ne vérifie pas que l'utilisateur authentifié a bien le droit d'accéder à cet objet. L'attaquant modifie l'ID pour accéder aux données d'autres utilisateurs.

Exemples typiques : (1) https://app.com/api/invoice/12345 — changer pour 12346 affiche la facture d'un autre client ; (2) /user/profile?id=42 — énumérer les profils d'autres utilisateurs ; (3) /download?file=report_2024.pdf — modifier pour accéder à des fichiers internes. C'est l'une des vulnérabilités les plus communes en bug bounty (souvent classée comme Broken Access Control, A01 dans OWASP Top 10 2021 — première position).

Mitigations : (1) toujours vérifier l'autorisation côté serveur : `if (invoice.owner_id != current_user.id) deny()` ; (2) utiliser des identifiants opaques imprédictibles (UUIDv4, KSUID, ULID) plutôt que des IDs séquentiels ; (3) implémenter un middleware d'autorisation centralisé (Cancan/Pundit en Ruby, Casbin, OPA, Cedar) ; (4) tests automatisés d'autorisation (BAC tests). Attention : l'obfuscation par UUID n'est pas une mitigation suffisante — c'est la vérification d'autorisation qui compte. Des outils comme Burp Suite Autorize ou Authmatrix aident à détecter les IDOR.