Comment fonctionne un IDOR ?
L'application utilise un identifiant prévisible (numéro séquentiel, UUID devinable) pour accéder aux ressources sans vérifier que l'utilisateur connecté a le droit d'y accéder. Exemple : changer /api/factures/1234 en /api/factures/1235 pour accéder à la facture d'un autre client.
Pourquoi les IDOR sont dangereux ?
Un scanner générique peut manquer une IDOR faute de connaître les droits attendus. Des tests multi-comptes, manuels ou automatisés avec des assertions d'autorisation, sont nécessaires pour vérifier les accès entre utilisateurs et tenants. L'impact va de la fuite de données personnelles à la modification de comptes, la suppression de ressources ou l'escalade de privilèges.
Comment prévenir les IDOR ?
- Vérifier systématiquement les permissions côté serveur avant chaque accès à une ressource.
- Utiliser des identifiants non prédictibles (UUID v4) en défense complémentaire, jamais comme remplacement du contrôle des droits.
- Implémenter un contrôle d'accès centralisé (RBAC/ABAC).
- Tester les IDOR dans chaque pentest applicatif, notamment lors d'un audit de sécurité d'API.
Exemple pédagogique : IDOR sur une API REST SaaS
Une PME SaaS B2B expose une API pour que chaque client consulte ses factures :
GET /api/v1/invoices/7842
Authorization: Bearer eyJhbGc...
200 OK
{ "id": 7842, "customer_id": 42, "amount": 1250, "pdf_url": "..." }Le back-end vérifie que le token JWT est valide, mais ne vérifie pas que la facture 7842 appartient bien au client authentifié. Un attaquant énumère simplement les IDs de 1 à 10 000 et récupère toutes les factures de tous les clients : nom, SIREN, CA, coordonnées bancaires.
Criticité : calculer un vecteur CVSS selon les privilèges requis et les impacts réellement démontrés ; lecture seule ne signifie pas une note unique. Le filtrage suivant illustre un contrôle d'isolation, à compléter par les droits sur l'objet et l'opération : WHERE customer_id = :current_user_tenant_id dans la requête SQL.
Dans un SaaS multi-tenant, testez aussi les exports, les pièces jointes et les tâches asynchrones : le tenant doit venir de la session validée, jamais d'un paramètre client non contrôlé. Notre audit de sécurité SaaS cadre ces parcours avec une matrice des rôles et tenants.
Références : OWASP : prévention IDOR ; A01:2025 ; RGPD article 33.
Recevoir la checklist OWASP Top 10 (PDF imprimable)
Les 10 risques OWASP 2025 traduits en contrôles de remédiation à cocher pour vos équipes dev et sécurité. Indiquez votre email professionnel pour y accéder immédiatement.
Valider le correctif d’une faille IDOR
Dans un environnement autorisé avec des données fictives, vérifiez la lecture, la modification et l’export. Un seul refus ne suffit pas.
- Compte A, objet autorisé de A : opération permise et résultat attendu.
- Compte A, objet de B : accès refusé sans révéler les données de B.
- Compte A, rôle insuffisant dans son propre tenant : opération interdite.
- Tenant injecté dans les paramètres : ignoré ou refusé ; le contexte provient de la session validée.
Conservez les rôles, la version testée et les résultats. Le compte rendu de contre-test doit préciser les chemins non vérifiés.
FAQ IDOR
Pourquoi les IDOR échappent aux scanners automatisés ?
Parce qu'un scanner ne sait pas qu'un utilisateur A ne doit pas accéder aux données de B. C'est une vulnérabilité de logique métier : techniquement l'application répond 200 OK, aucun signal anormal. Des tests avec plusieurs comptes et une matrice de droits peuvent le détecter, manuellement ou avec une automatisation configurée pour vérifier les autorisations.
Les UUID protègent-ils des IDOR ?
Partiellement. Un UUID v4 correctement généré rend la découverte par devinette très improbable, mais un IDOR reste exploitable dès qu'un UUID fuite (URL partagée, logs, références croisées). L'UUID est une défense en profondeur, pas un contrôle d'accès.
Un IDOR impacte-t-il ma conformité RGPD ?
Une faille seule ne démontre pas qu’une violation a eu lieu. Qualifiez les accès illégitimes et les données affectées. Si une violation est susceptible d’engendrer un risque pour les personnes, le responsable du traitement notifie la CNIL dans les meilleurs délais et, si possible, sous 72 heures après en avoir pris connaissance (article 33). Les sanctions dépendent du manquement et ne sont pas automatiques.
Les IDOR sont-ils classés dans OWASP Top 10 ?
Oui, catégorie A01:2025 Broken Access Control. L'OWASP API Security Top 10 les classe aussi en API1:2023 BOLA (Broken Object Level Authorization). Voir notre article OWASP API Security Top 10.