IDOR / BOLA — Vue d'ensemble

Qu'est-ce que l'IDOR ?#

Une référence directe à un objet non sécurisée (IDOR) survient quand une application utilise une entrée contrôlée par l'utilisateur — segment de chemin d'URL, paramètre de requête, champ de corps de requête, ou en-tête HTTP — pour chercher un objet interne directement, sans vérifier que l'utilisateur authentifié est autorisé à accéder à cet objet spécifique. L'application authentifie correctement l'utilisateur mais omet la deuxième étape : confirmer que l'identité authentifiée possède ou s'est vu accorder l'accès à la ressource demandée.

L'IDOR est classifié CWE-639 (Authorization Bypass Through User-Controlled Key) et constitue la principale classe de vulnérabilité au sein d'OWASP A01:2021 et A01:2025 — Contrôle d'accès défaillant. Dans le contexte de la sécurité API, son équivalent se nomme BOLA (Broken Object Level Authorization), position API1:2023 de l'OWASP API Security Top 10. La distinction est terminologique : IDOR et BOLA décrivent la même cause racine appliquée dans des contextes web et API respectivement.

La vulnérabilité persiste à grande échelle car la plupart des frameworks d'authentification imposent correctement l'identité, mais l'autorisation au niveau objet — vérifier que cette identité peut accéder à cet enregistrement spécifique — nécessite une implémentation délibérée par endpoint. Quand les développeurs supposent que l'authentification est suffisante, ou quand la logique d'autorisation est appliquée dans l'interface utilisateur mais pas dans la couche API, l'IDOR en résulte.

Mécanisme#

Le gap d'autorisation a trois causes racines dans le code de production :

1. Authentification sans autorisation — le serveur valide le token de session (confirme l'identité) mais récupère l'objet en utilisant l'ID fourni par le client sans une deuxième clause WHERE owner_id = ?.
2. Contrôle d'accès uniquement dans l'UI — les endpoints admin sont cachés dans le frontend mais les routes API sous-jacentes manquent d'enforcement par middleware ; les requêtes HTTP directes contournent entièrement l'UI.
3. Mass assignment — le binding automatique des frameworks mappe tous les champs du corps de requête aux propriétés du modèle, y compris les champs protégés (role, is_admin, tenant_id) que l'utilisateur ne devrait jamais contrôler.

# VULNÉRABLE — authentifie mais n'autorise pas
@router.get("/api/factures/{facture_id}")
async def obtenir_facture(facture_id: int, user: User = Depends(get_current_user)):
    facture = await db.get(Facture, facture_id)  # récupère N'IMPORTE QUELLE facture
    return facture
 
# SÉCURISÉ — propriété imposée au niveau requête de base de données
@router.get("/api/factures/{facture_id}")
async def obtenir_facture(facture_id: int, user: User = Depends(get_current_user)):
    facture = await db.execute(
        select(Facture)
        .where(Facture.id == facture_id)
        .where(Facture.owner_id == user.id)  # verrou de propriété
    )
    if not facture:
        raise HTTPException(status_code=404)  # 404 pas 403 — évite l'oracle d'existence
    return facture

Variantes d'IDOR#

Référence directe à un objet#

La forme la plus simple : les clés primaires auto-incrémentées apparaissent dans les URLs ou les corps de requête. Un attaquant incrémente ou décrémente l'ID pour accéder aux enregistrements adjacents. La violation Optus (2022) a exploité exactement ce pattern — GET /api/customers/1 jusqu'à GET /api/customers/9800000 a exfiltré 9,8 millions d'enregistrements sans authentification.

Escalade horizontale de privilèges#

L'utilisateur A et l'utilisateur B partagent le même rôle. L'utilisateur A substitue l'identifiant de ressource de B dans une requête authentifiée comme A. L'application valide la session de A mais ne vérifie pas si A possède la ressource référencée. Il s'agit du sous-type IDOR le plus courant et il représente la majorité des rapports bug bounty de haute sévérité. La violation McHire de McDonald's (juillet 2025, 64 millions d'enregistrements) était un IDOR horizontal sur le paramètre lead_id.

Escalade verticale de privilèges (BFLA)#

Un utilisateur normal invoque des endpoints ou fonctions réservés aux rôles privilégiés. Contrairement à l'IDOR horizontal — qui concerne l'accès aux données d'un pair — l'escalade verticale concerne l'invocation de fonctions privilégiées. CVE-2025-27507 dans la plateforme d'identité ZITADEL (CVSS 9,0) permettait à des utilisateurs non-admin d'appeler 12 endpoints gRPC de l'Admin API, incluant la modification de la configuration LDAP, atteignant la prise de contrôle totale de compte pour tous les utilisateurs LDAP de l'instance.

Référence indirecte à un objet#

L'application utilise un identifiant secondaire — un nom de fichier, code de référence, hash ou token opaque — qui semble impossible à deviner mais est réversible ou énumérable. md5(user_id) est trivialement calculable. Les IDs encodés en Base64 se décodent immédiatement. Les horodatages UUID v1 sont prévisibles dans une fenêtre temporelle. Le point essentiel : l'opacité n'est pas une autorisation.

IDOR via Mass Assignment#

Les frameworks API qui lient les champs du corps de requête directement aux objets du modèle ORM permettent aux attaquants de définir des champs que l'application n'a jamais eu l'intention de rendre inscriptibles par l'utilisateur : role, is_admin, account_balance, tenant_id. CVE-2024-7297 dans Langflow (CVSS 8,8) permettait à tout utilisateur authentifié d'obtenir un accès super-admin en envoyant {"is_superuser": true} à un endpoint PATCH.

Exemples réels#

Optus (septembre 2022) — Un endpoint REST /api/customers/{id} retournait des enregistrements clients indexés par entiers séquentiels sans authentification. GET /api/customers/1 jusqu'à 9,8 millions d'itérations a exfiltré noms, dates de naissance, numéros de passeport et de permis de conduire. Résultat réglementaire : amende ACMA de 1,36 million AUD.

McDonald's McHire (juillet 2025) — Les chercheurs Ian Carroll et Sam Curry ont découvert que le paramètre lead_id sur /api/lead/cem-xhr était un entier séquentiel. Le décrémenter ou l'incrémenter retournait le transcript de chat complet d'un autre candidat incluant nom, téléphone, email et résultats de tests de personnalité. Échelle : 64 millions d'enregistrements. Remédié dans les 24 heures suivant la divulgation.

CVE-2025-27507 — ZITADEL (CVSS 9,0, Critique) — 12 endpoints HTTP de l'Admin API imposaient des permissions IAM au niveau organisation au lieu du niveau système. Des utilisateurs non-admin authentifiés modifiaient la configuration LDAP, redirigeant l'authentification vers un serveur malveillant et interceptant les credentials de tous les utilisateurs LDAP de l'instance. Affectait ZITADEL 2.x sur huit branches de versions.

HackerOne #2122671 — Plateforme HackerOne (12 500 $) — Une mutation GraphQL permettait la suppression des certifications et licences de n'importe quel utilisateur. Le champ id de l'objet dans la mutation n'était pas validé contre l'identité de l'appelant. La plateforme qui gère les programmes bug bounty était elle-même vulnérable à l'IDOR.

HackerOne #415081 — PayPal (10 500 $) — La manipulation de paramètre sur /businessmanage/users/api/v1/users accordait la création de compte secondaire sur les comptes business des victimes, permettant la prise de contrôle de compte.

Détection#

Tests manuels#

1. Créer deux comptes : Utilisateur A et Utilisateur B, chacun avec des ressources possédées (commandes, documents, profils).
2. Depuis la session de l'utilisateur A, noter les identifiants de ressource visibles dans les réponses pour les ressources de A.
3. Depuis la session de l'utilisateur A, substituer les identifiants de ressource de B dans les requêtes sur toutes les méthodes HTTP : GET, PUT, PATCH, DELETE.
4. Tester tous les emplacements de paramètre : chemin d'URL (/api/commandes/1338), chaîne de requête (?order_id=1338), corps de requête ({"order_id": 1338}), et en-têtes HTTP (X-User-ID: 1338).
5. Confirmer : si l'utilisateur A récupère les données de B → IDOR confirmé. Si le serveur retourne 403 ou 404 de façon constante → protégé.
6. Pour le mass assignment : envoyer des requêtes PUT/PATCH avec des champs supplémentaires (role, is_admin, balance). Faire suivre d'un GET pour vérifier la persistance.

Détection automatisée#

L'extension Burp Suite Autorize rejoue automatiquement chaque requête interceptée avec le cookie de session d'un second utilisateur, colorant les réponses selon l'état du contrôle d'accès. AuthMatrix définit une matrice de permissions rôle × endpoint et teste toutes les combinaisons. Les outils automatisés ont une limitation fondamentale : ils ne peuvent pas raisonner sur la propriété d'objet sans relations de ressources définies par un humain.

BreachVex détecte l'IDOR via une approche différentielle multi-signaux : il sonde les IDs adjacents, compare les corps de réponse entre deux sessions authentifiées, et corrobore les findings par des signaux complémentaires — un différentiel de code de statut (403→200), echo d'ID dans le corps de réponse, divergence de champs PII, et comparaison de structure JSON. La détection de mass assignment injecte une large liste de champs de privilège dans les endpoints POST/PUT/PATCH et confirme via une re-lecture GET.

Prévention#

Imposer la propriété au niveau de la couche base de données#

Dériver l'identité utilisateur exclusivement de la session authentifiée. Chaque requête sur une ressource appartenant à un utilisateur doit inclure la contrainte de propriété structurellement — pas comme une vérification optionnelle qu'un développeur futur pourrait omettre.

-- VULNÉRABLE — récupère n'importe quel enregistrement par ID
SELECT * FROM orders WHERE order_id = ?;
 
-- SÉCURISÉ — la propriété est une contrainte structurelle de requête
SELECT * FROM orders WHERE order_id = ? AND owner_id = ?;
 
-- Multi-tenant : ajouter le scope tenant
SELECT * FROM orders WHERE order_id = ? AND owner_id = ? AND tenant_id = ?;

Utiliser UUID v4 pour les identifiants exposés#

Ne pas exposer d'entiers auto-incrémentés dans les API publiques. L'UUID v4 (cryptographiquement aléatoire, 2¹²² valeurs possibles) prévient l'IDOR basé sur l'énumération. L'UUID v1 (dérivé d'un horodatage) est partiellement prévisible et doit être évité pour les tokens de sécurité (CVE-2024-45719). Les UUID ne remplacent pas l'autorisation — ils sont des contrôles de limitation du débit sur les tentatives de devinette.

Listes d'autorisation explicites de champs (Mass Assignment)#

Utiliser la validation de schéma qui déclare exactement quels champs sont inscriptibles. Les champs absents du schéma ne peuvent pas être soumis quel que soit ce qu'envoie le client.

# FastAPI / Pydantic — seuls les champs déclarés sont inscriptibles
class DemandeMAJUtilisateur(BaseModel):
    nom_affiche: str
    bio: str | None = None
    # is_admin, role, tenant_id : NON déclarés → rejetés automatiquement
 
@router.patch("/utilisateurs/moi")
async def maj_utilisateur(user_id: str = Depends(get_current_user_id),
                          data: DemandeMAJUtilisateur):
    await db.users.update(id=user_id, **data.model_dump(exclude_unset=True))

PostgreSQL Row-Level Security (défense en profondeur)#

RLS impose la propriété au niveau de la base de données, empêchant l'IDOR même si le code applicatif présente un défaut :

ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
CREATE POLICY orders_isolation ON orders
  USING (owner_id = current_setting('app.current_user_id')::int);
-- Dans la configuration de connexion FastAPI : SET app.current_user_id = {user.id}

Ressources#

• OWASP IDOR Prevention Cheat Sheet
• OWASP API Security — API1:2023 BOLA
• PortSwigger — Insecure Direct Object References
• NVD — CVE-2025-27507 (ZITADEL)