IDOR

01 — DéfinitionQu'est-ce qu'une IDOR ?

L'IDOR (Insecure Direct Object Reference) est une faille d'autorisation permettant à un utilisateur authentifié d'accéder à des ressources appartenant à d'autres utilisateurs en modifiant un identifiant dans une URL, un paramètre ou le corps d'une requête.

Authentification vs autorisation

• Authentification : « Qui êtes-vous ? » — login, MFA, SSO.
• Autorisation : « Avez-vous le droit d'accéder à ceci ? »

L'IDOR est un échec d'autorisation. L'utilisateur est bien authentifié mais le serveur oublie de vérifier qu'il a le droit d'accéder à cette ressource précise.

Exemple canonique

GET /api/invoices/42
Cookie: session=alice-valid

Le serveur vulnérable :

// Code vulnérable
function getInvoice(req, res) {
  const id = req.params.id;
  const invoice = db.invoices.findById(id);
  res.json(invoice);  // ❌ Pas de vérification
}

Alice peut simplement changer l'ID : /api/invoices/43 → facture de Bob, /api/invoices/44 → facture de Charlie. Fuite de toutes les factures en quelques requêtes.

Pourquoi c'est si fréquent

• Facilité d'oubli : chaque endpoint doit vérifier, un seul oubli suffit.
• Tests insuffisants : les tests unitaires couvrent rarement le cas « autre utilisateur qui accède ».
• Frameworks n'imposent pas la vérification d'autorisation par ressource.
• Croissance APIs : nouveaux endpoints oublient parfois la logique.

L'IDOR est l'incarnation moderne de la règle « ne jamais faire confiance au client ». Tout paramètre qui désigne une ressource doit être validé côté serveur. Oubli trivial, impact massif : voilà pourquoi cette faille reste en tête des bug bounties depuis 15 ans.

02 — ExploitationMéthode d'un attaquant

Méthodologie

1. Identifier les endpoints avec IDs dans l'URL ou les paramètres.
2. Changer l'ID à une valeur proche (+1, -1).
3. Observer : la réponse contient-elle des données d'un autre utilisateur ?
4. Automatiser pour énumérer toutes les valeurs possibles.
5. Évaluer la sensibilité des données accessibles.

Outils

• Burp Suite : intercepter + modifier, Intruder pour énumérer.
• Burp AuthMatrix / Autorize : plugins qui testent systématiquement avec différents utilisateurs.
• ffuf, wfuzz : fuzzing d'IDs.
• curl, Postman en scripts : automatisation simple.

Endroits où chercher

• URL paths : /users/42, /orders/123.
• Query strings : ?user_id=42, ?account=bob.
• Request body : champs JSON indiquant une cible.
• Headers custom : X-User-ID (mauvais design).
• Cookies manipulés.
• JWT mal signés, acceptés avec alg: none.
• GraphQL : IDs dans les variables.
• Endpoints de téléchargement : /download?file=42.pdf.

Types d'identifiants

• IDs séquentiels (1, 2, 3...) : énumération triviale, les plus exploitables.
• UUIDs v4 : ~impossibles à deviner mais peuvent fuiter (pages publiques, logs, autres endpoints).
• Hashes : prédictibles si dérivés d'un email ou d'une donnée connue.
• Slugs (texte lisible) : énumération par dictionnaire.

Exemple concret

App de livraison de repas :

GET /api/v1/orders/84521
Authorization: Bearer {token_alice}

Alice teste des IDs voisins :

GET /api/v1/orders/84520 → commande de Bob (adresse, items, prix)
GET /api/v1/orders/84519 → commande de Carol
...

Une boucle simple énumère des milliers de commandes avec noms, adresses, téléphones en quelques heures.

Impact selon la ressource

• Profils : fuite PII — violation RGPD.
• Documents : contrats, factures, dossiers médicaux.
• Messages : conversations privées.
• Transactions financières : comptes, soldes, virements.
• Admin features : escalade de privilège.
• Configuration : modification de paramètres critiques.

03 — TypesVariantes

IDOR en lecture (GET)

Le plus fréquent. L'attaquant lit les données d'un autre utilisateur. Impact : fuite (confidentialité).

IDOR en modification (POST/PUT/PATCH)

PUT /api/users/{id}/settings
{"email": "pirate@evil.com"}

Si {id} peut être celui d'un autre utilisateur : changer email, puis récupérer un reset password, verrouiller le compte.

IDOR en suppression (DELETE)

DELETE /api/posts/{id}
DELETE /api/account/{id}

Impact sur intégrité et disponibilité.

Mass assignment

L'attaquant envoie des champs supplémentaires :

POST /api/users/profile
{
  "name": "Alice",
  "email": "alice@example.com",
  "is_admin": true,           // ← non documenté
  "account_balance": 999999
}

Si le serveur fait User.create(req.body) sans filtrer, tous les champs sont acceptés. Vulnérabilité classique en Rails (incident historique GitHub 2012).

Horizontal vs vertical

• Horizontal : accès aux ressources d'utilisateurs de même niveau (user → user).
• Vertical : escalade vers niveau supérieur (user → admin). Plus grave.

Force browsing

Deviner des URLs d'administration non liées : /admin, /debug. Même famille (Broken Access Control) sans être strictement IDOR.

04 — BOLAIDOR dans les APIs

OWASP API Security Top 10

OWASP maintient un Top 10 distinct pour les APIs (2019, MAJ 2023). La vulnérabilité #1 : API1:2023 Broken Object Level Authorization (BOLA).

BOLA = IDOR côté API

Même classe de vulnérabilité, vocabulaire différent :

• Object Level : accès à un objet spécifique.
• Authorization : vérification du droit.
• Broken : défaillant.

Pourquoi les APIs sont particulièrement touchées

• Granularité : chaque endpoint = risque d'oubli.
• Mobile-first apps : APIs mobiles moins contrôlées que le web, facilement interceptables.
• Microservices : chaque service implémente son auth.
• Croissance : centaines d'endpoints dans apps modernes.
• GraphQL : flexibilité complique les contrôles.

Top 10 API OWASP 2023

• API1 — BOLA : #1 IDOR API.
• API2 — Broken Authentication.
• API3 — Broken Object Property Level Authorization : mass assignment notamment.
• API4 — Unrestricted Resource Consumption.
• API5 — Broken Function Level Authorization.
• API6 — Unrestricted Access to Sensitive Business Flows.
• API7 — SSRF.
• API8 — Security Misconfiguration.
• API9 — Improper Inventory Management.
• API10 — Unsafe Consumption of APIs.

Statistiques bug bounty

BOLA représente systématiquement 25-40% des vulnérabilités API trouvées (HackerOne, Bugcrowd). Bounties typiques : 2 000 - 25 000 USD selon criticité.

05 — IncidentsCas publics

First American Financial Corp (mai 2019)

• 885 millions de documents exposés.
• IDOR sur URL de documents : incrémenter l'ID = lire tous les documents.
• Crédits immobiliers, SSN, images de passeports et permis.
• Découvert par le journaliste Brian Krebs.

US Postal Service (novembre 2018)

• IDOR dans l'API USPS exposait 60 millions d'utilisateurs.
• Corrigée après notification.

Parler (janvier 2021)

• Hacker « donk_enby » archive ~99% des posts avant takedown.
• IDs séquentiels + autorisation insuffisante.
• Plusieurs téraoctets exfiltrés.

Optus — Australie (septembre 2022)

• 10 millions de dossiers.
• API mal sécurisée, énumération d'IDs clients.

T-Mobile (janvier 2023)

• 37 millions de comptes via API mal protégée.
• T-Mobile a eu plusieurs incidents similaires.

GitHub 2012 — mass assignment

Egor Homakov exploite une mass assignment dans GitHub (Rails) pour ajouter sa clé SSH au compte d'un admin et commiter dans le dépôt Rails lui-même. Corrigé en heures. A popularisé le « strong parameters » en Rails.

Bug bounty continu

• Facebook, Shopify, Uber, DoorDash : bounties 5k-40k USD régulièrement.
• Healthtech et fintech : secteurs critiques fréquemment visés.

06 — ProtectionBonnes pratiques

// Code sécurisé
function getInvoice(req, res) {
  const invoice = db.invoices.findById(req.params.id);
  if (!invoice) return res.status(404).json({error: 'Not found'});
  if (invoice.user_id !== req.user.id) {
    return res.status(403).json({error: 'Forbidden'});
  }
  res.json(invoice);
}

07 — FAQQuestions fréquentes

Les UUIDs suffisent-ils pour empêcher les IDOR ?

Non. Les UUIDs v4 aléatoires compliquent l'énumération brute force (128 bits d'entropie) mais ne remplacent pas la vérification d'autorisation. Un UUID peut fuiter : logs serveur, emails envoyés aux utilisateurs, pages publiques, référenceurs HTTP, erreurs applicatives, autres endpoints. Si l'application récupère la ressource sans vérifier les droits, un UUID leaké = IDOR exploitable. Les UUIDs sont de la défense en profondeur, pas une solution de fond. La solution reste toujours la vérification d'autorisation côté serveur pour chaque requête.

Pourquoi IDOR est-elle en tête OWASP Top 10 ?

Depuis 2021, Broken Access Control (qui inclut IDOR) est passé de la 5e à la 1re place de l'OWASP Top 10. Raisons : l'analyse des données CVE et pentests a montré que c'était la famille la plus fréquemment détectée (94% des applications analysées avaient au moins une faille d'access control). La croissance des APIs et microservices a multiplié les surfaces où oublier les vérifications. L'impact est souvent massif : fuite de toutes les données utilisateurs en une faille. Les outils de pentest modernes trouvent facilement ces failles. Pourtant, elles persistent partout.

Quelle différence IDOR et Broken Access Control ?

IDOR est une sous-catégorie de Broken Access Control. Broken Access Control couvre tous les échecs de contrôle d'accès : IDOR, force browsing, function-level authorization broken, privilege escalation, missing authentication sur endpoints sensibles, CORS misconfiguré, bypass d'authentification. IDOR désigne spécifiquement le cas où un identifiant d'objet permet d'accéder à d'autres instances. En pratique : quand on parle d'IDOR, on parle du cas le plus commun de Broken Access Control.

Les frameworks modernes préviennent-ils les IDOR ?

Partiellement. Les frameworks proposent des outils de vérification mais ne les imposent pas. Django propose des permission classes, Rails propose Pundit/CanCanCan, Spring propose @PreAuthorize. Mais ils ne forcent pas leur usage sur chaque endpoint. Certains frameworks récents tentent d'imposer plus structurellement : les ORMs avec row-level security (Prisma Row-Level Security, PostgREST), les API gateways avec policies centralisées (Kong, AWS API Gateway authorizers). Le vrai progrès viendra peut-être des frameworks qui rendront la vérification d'autorisation obligatoire par défaut pour tout accès à une ressource identifiée.

Comment détecter les IDOR sur mon application ?

Approche structurée. 1. Inventaire : lister tous les endpoints qui acceptent un ID en paramètre. 2. Tests manuels : pour chaque endpoint, créer 2 comptes de test, vérifier que l'un ne peut pas accéder aux ressources de l'autre. 3. Outils automatisés : Burp Suite AuthMatrix, OWASP ZAP, plugins dédiés. 4. Code review : chercher les patterns findById(req.params.id) ou équivalent sans vérification de propriétaire. 5. Tests d'intégration : ajouter pour chaque endpoint un test qui tente d'accéder avec un utilisateur non autorisé. 6. Bug bounty : laisser les chercheurs externes trouver ce qui vous échappe. 7. Logs : analyser les accès — patterns d'énumération d'IDs = scan potentiel.

L'IDOR est-elle déclarable RGPD ?

Oui, une IDOR exploitée entraînant une fuite de données personnelles constitue une violation de données personnelles au sens du RGPD. Obligations : notifier la CNIL sous 72h (article 33 RGPD), informer les personnes concernées si risque élevé (article 34), documenter l'incident dans le registre des violations. L'existence d'une faille IDOR découverte mais pas exploitée ne constitue pas une violation notifiable (pas de données effectivement compromises), mais la confirmer par pentest ou bug bounty est prudent. Sanctions CNIL possibles en cas de faille structurelle démontrée : de quelques k€ (petite entreprise) à plusieurs millions d'€ (grand groupe) selon criticité et gestion.