Retour au blog
APIIDORBOLA

BOLA et IDOR : pourquoi votre API expose les données d'autres clients

Publié le 2026-04-057 min de lectureFlorian

BOLA et IDOR, c'est la même chose ?

Presque. IDOR (Insecure Direct Object Reference) est le terme historique. BOLA (Broken Object Level Authorization) est le terme utilisé par l'OWASP API Security Top 10 depuis 2019. Le concept est identique : un utilisateur authentifié accède aux ressources d'un autre utilisateur en manipulant l'identifiant de la ressource dans la requête.

Pourquoi c'est si fréquent

Les frameworks web facilitent la création de routes CRUD. Un développeur crée GET /api/documents/:id et le contrôleur récupère le document par son ID. Mais la vérification que l'utilisateur connecté est autorisé à voir ce document est une étape manuelle. Aucun framework ne l'ajoute automatiquement. Il faut explicitement écrire if (document.userId !== currentUser.id) return 403.

Facteur aggravant : les identifiants séquentiels. Si les IDs sont 1, 2, 3, 4..., l'attaquant peut tous les énumérer. Les UUID réduisent le risque d'énumération mais ne remplacent pas le contrôle d'autorisation.

Techniques d'exploitation

Énumération directe

L'attaquant parcourt une plage d'IDs : GET /api/users/1, GET /api/users/2, etc. Avec un script automatisé, des milliers de profils sont extraits en quelques minutes.

Manipulation de paramètres

Changer user_id dans le body d'une requête POST ou PATCH. Si POST /api/transfer accepte {"from_account": "attacker", "to_account": "victim", "amount": 1000} sans vérifier que l'appelant possède le compte source, c'est un BOLA critique.

GraphQL et nested queries

En GraphQL, un attaquant peut naviguer dans les relations : query { user(id: 42) { documents { content } } }. Si la résolution du type User ne vérifie pas l'autorisation, les documents de n'importe quel utilisateur sont accessibles.

Via les fichiers et médias

Les URLs de téléchargement avec des IDs prévisibles : /api/files/invoice_1042.pdf. L'attaquant modifie le numéro de facture pour accéder aux documents d'autres clients.

Défenses

  • Contrôle systématique : chaque endpoint doit vérifier que l'utilisateur connecté est propriétaire ou a les droits sur la ressource demandée. Pas d'exception.
  • Middleware d'autorisation : centralisez la logique dans un middleware plutôt que dans chaque contrôleur. Un oubli dans un seul contrôleur suffit à créer une faille.
  • Row Level Security : sur Supabase et PostgreSQL, les policies RLS vérifient l'autorisation directement au niveau de la base de données. Même si le code applicatif oublie un contrôle, la base bloque l'accès.
  • Identifiants non prédictibles : utilisez des UUID v4 plutôt que des entiers séquentiels. Cela n'élimine pas le risque mais rend l'énumération impraticable.
  • Tests d'autorisation automatisés : pour chaque endpoint, écrivez un test qui vérifie qu'un utilisateur B ne peut pas accéder aux ressources de l'utilisateur A.
  • Impact réel

    Les BOLA permettent l'exfiltration massive de données personnelles. En termes RGPD, c'est une violation de données à notifier à la CNIL sous 72 heures. Chez CleanIssue, nous identifions des BOLA dans environ 40% des API auditées. Parlez-nous de votre revue externe.

    Articles liés

    Trois analyses proches pour continuer la lecture sur la meme surface de risque.

    Sources

    Rédigé par Florian
    Revu le 2026-04-05

    Analyse éditoriale fondée sur la documentation officielle des éditeurs, projets et autorités concernées.

    Services associés

    Si ce sujet reflète un risque concret sur votre stack, voici les audits CleanIssue les plus pertinents.

    Besoin d'une revue externe de votre SaaS RH ?

    Expliquez votre produit, votre stack et votre contexte client. Nous revenons vers vous avec le bon niveau de revue.

    Parler de votre audit