Les IDOR (Insecure Direct Object Reference) sont les vulnérabilités les plus fréquemment trouvées par les débutants en bug bounty — et pour cause. Elles sont logiquement simples à comprendre, faciles à tester manuellement, et peuvent avoir un impact sévère. Pourtant, elles restent très répandues, même dans de grandes applications.
Ce guide vous explique tout : la théorie, les exemples concrets, la méthodologie de détection, et comment rédiger un rapport IDOR convaincant.
Qu’est-ce qu’un IDOR ?
Un IDOR est une vulnérabilité de contrôle d’accès (Broken Access Control dans l’OWASP Top 10). Elle survient quand une application :
- Utilise un identifiant directement accessible à l’utilisateur (dans l’URL, un paramètre POST, un header…)
- Ne vérifie pas que l’utilisateur connecté a le droit d’accéder à la ressource correspondante
En résultat : un attaquant peut manipuler cet identifiant pour accéder aux données d’autres utilisateurs.
Exemple minimal
GET /api/invoices/12345
Authorization: Bearer token_user_A
En changeant 12345 par 12346, vous accédez à la facture de l’utilisateur B — sans être lui. C’est un IDOR.
L’erreur est côté serveur : il ne vérifie pas "l'invoice 12346 appartient-elle bien à l'utilisateur A ?".
Pourquoi les IDORs sont-ils si fréquents ?
Plusieurs raisons expliquent leur persistance :
1. Les développeurs font confiance au client L’erreur classique : penser que si l’interface ne montre pas le bouton “Voir les factures des autres”, personne ne peut y accéder.
2. Les frameworks n’appliquent pas de contrôles automatiques Contrairement aux XSS (souvent mitigées par l’échappement automatique), le contrôle d’accès doit être implémenté manuellement pour chaque endpoint.
3. Les tests de sécurité classiques le détectent mal Les scanners automatiques ne comprennent pas la logique métier. Seul un humain qui crée deux comptes et compare peut tester efficacement les IDORs.
Les différents types d’IDOR
IDOR sur des objets GET (lecture)
Le plus courant. On accède à une ressource appartenant à un autre utilisateur :
# Votre profil
GET /api/users/profile?id=1001
# Profil d'un autre utilisateur
GET /api/users/profile?id=1002 → ✅ IDOR si accessible
IDOR sur des actions (write/delete)
Plus impactant. On modifie ou supprime les données d’un autre utilisateur :
# Modifier l'adresse email d'un autre utilisateur
POST /api/users/update
{"user_id": "1002", "email": "hacker@evil.com"}
# Supprimer le compte d'un autre utilisateur
DELETE /api/users/1002
IDOR indirect (via paramètre POST/JSON)
L’identifiant n’est pas dans l’URL mais dans le corps de la requête :
POST /api/documents/download
Content-Type: application/json
{"document_id": "DOC-7890", "user_id": "1001"}
En changeant document_id ou user_id, vous pouvez accéder à des documents qui ne vous appartiennent pas.
IDOR sur des fichiers
GET /uploads/invoices/user_1234/invoice_2024_01.pdf
En changeant user_1234 par user_1235, vous accédez aux fichiers d’un autre utilisateur — si le serveur ne vérifie pas les droits.
IDOR sur des UUIDs
GET /api/orders/550e8400-e29b-41d4-a716-446655440000
Les UUIDs semblent “sécurisés” car imprévisibles, mais :
- Si l’application expose les UUIDs via d’autres endpoints (ex: liste de commandes publique)
- Ou via des informations dans d’autres réponses API
…ils peuvent être exploités.
Méthodologie de détection des IDORs
Étape 1 : Créer deux comptes
La base absolue. Créez deux comptes séparés sur l’application cible (compte A et compte B). Utilisez deux sessions/navigateurs différents.
Dans Burp Suite : ouvrez deux fenêtres Firefox avec des cookies différents, ou utilisez l’extension Autorize pour tester automatiquement avec la session B.
Étape 2 : Mapper tous les identifiants
En naviguant avec le compte A, notez tous les identifiants que vous croisez :
- IDs numériques séquentiels :
?id=1234,/users/1234 - UUIDs :
/documents/550e8400-... - Hashes :
/files/a94a8fe5ccb... - Noms de fichiers :
/uploads/user_john/photo.jpg - Paramètres POST :
{"account_id": "ACC-001"}
Étape 3 : Tester avec les IDs du compte B
Pour chaque identifiant trouvé, testez d’accéder aux ressources du compte B depuis la session du compte A.
Méthode manuelle (Burp Repeater) :
- Capturez la requête avec l’ID du compte A
- Envoyez vers le Repeater
- Remplacez l’ID par celui du compte B
- Analysez la réponse : si les données du compte B s’affichent → IDOR ✅
Méthode automatisée (extension Autorize) :
- Installez Autorize depuis le BApp Store
- Configurez le token/cookie de session du compte B dans Autorize
- Naviguez normalement avec le compte A
- Autorize teste automatiquement chaque requête avec la session B
- Les IDORs apparaissent en vert dans l’interface
Étape 4 : Tester les endpoints non documentés
Beaucoup d’IDORs se cachent dans des endpoints d’API non affichés dans l’interface :
# Avec ffuf
ffuf -u https://target.com/api/users/FUZZ -w /tmp/ids.txt -mc 200
# Avec Burp Intruder sur une plage d'IDs
Étape 5 : Chercher les IDORs d’action
Les IDORs d’action (write/delete) sont plus sévères et souvent oubliés. Testez :
- Les endpoints d’update de profil
- Les endpoints de suppression
- Les endpoints d’invitation ou de partage
- Les endpoints de paiement
Exemples réels de rapports IDOR payés
Exemple 1 : IDOR sur l’API de messages (Sévérité : High)
Endpoint vulnérable :
GET /api/v2/messages/thread/88234
Authorization: Bearer <token_user_A>
Test :
En changeant 88234 par 88235 (thread d’un autre utilisateur), toute la conversation privée était accessible.
Impact : Accès en lecture à toutes les conversations privées de la plateforme.
Prime reçue : 2 500€
Exemple 2 : IDOR d’action sur la suppression de compte (Sévérité : Critical)
Endpoint vulnérable :
POST /api/users/delete
Content-Type: application/json
{"user_id": "1001"}
Test :
En remplaçant 1001 par l’ID d’un autre utilisateur, il était possible de supprimer n’importe quel compte.
Impact : Suppression arbitraire de comptes utilisateurs.
Prime reçue : 8 000€
Exemple 3 : IDOR indirect dans un paramètre JSON imbriqué
Endpoint vulnérable :
POST /api/export/download
{
"format": "pdf",
"filters": {
"account": {
"id": "ACC-1234"
}
}
}
Le paramètre account.id n’était pas vérifié côté serveur.
Impact : Export de données comptables de n’importe quel compte.
Prime reçue : 3 000€
Comment rédiger un rapport IDOR parfait
Un bon rapport IDOR = une prime payée rapidement. Voici la structure idéale :
Titre
[IDOR] Accès non autorisé aux données de factures via manipulation de l'ID
Soyez précis : mentionnez le type de vulnérabilité, l’endpoint, et les données exposées.
Résumé
L'endpoint /api/invoices/{id} ne vérifie pas que l'invoice
appartient à l'utilisateur authentifié, permettant à tout
utilisateur connecté d'accéder aux factures de n'importe
quel autre utilisateur en manipulant le paramètre {id}.
Étapes de reproduction
1. Créer le compte A (email: test-a@test.com)
2. Créer le compte B (email: test-b@test.com)
3. Connecté en tant que A, créer une facture → noter l'ID : 12345
4. Connecté en tant que B, envoyer la requête :
GET /api/invoices/12345
Authorization: Bearer <token_B>
5. Observer que les données de la facture de A sont retournées
Preuve (PoC)
Joignez :
- Capture d’écran ou vidéo de la démonstration
- La requête Burp complète
- La réponse serveur avec les données de l’autre utilisateur (floutez les données sensibles réelles)
Impact
Cette vulnérabilité permet à tout utilisateur authentifié
de lire les factures de n'importe quel autre utilisateur,
exposant potentiellement : montants, adresses, informations
de paiement. L'impact est élevé car la confidentialité
des données de TOUS les utilisateurs est compromise.
Suggestion de correction
Vérifier côté serveur que l'invoice demandée appartient
bien à l'utilisateur authentifié avant de retourner les données.
Exemple pseudo-code :
if (invoice.user_id !== current_user.id) {
return 403 Forbidden;
}
Les pièges à éviter
Tester sur de vraies données utilisateurs : ne téléchargez pas, ne modifiez pas, ne supprimez pas les vraies données d’autres utilisateurs. Prouvez la vulnérabilité avec vos deux comptes de test et arrêtez-vous là.
Aller trop loin dans l’exploitation : une capture d’écran prouvant l’accès suffit. Pas besoin de dumper toute la base de données.
Oublier de vérifier le scope : certains programmes excluent les IDORs sur certains endpoints. Vérifiez le scope avant de soumettre.
Envoyer un rapport incomplet : sans étapes de reproduction précises, votre rapport risque d’être ignoré ou classé “informative”.
Conclusion
Les IDORs sont la porte d’entrée idéale en bug bounty. Elles vous apprennent à penser en termes de contrôle d’accès, à utiliser Burp Suite efficacement, et à rédiger des rapports de qualité.
Commencez par créer deux comptes sur n’importe quelle application en scope, et regardez partout où des IDs apparaissent. Avec de la méthode et de la persévérance, votre premier rapport payé n’est peut-être qu’à quelques programmes de vous.
Pour aller plus loin et maîtriser toutes les vulnérabilités du bug bounty de manière structurée, avec des labs pratiques et un accompagnement, découvrez notre formation complète.