IDOR

IDOR (Insecure Direct Object Reference, référence directe non sécurisée à un objet) est une vulnérabilité où l’application utilise un identifiant issu de la requête, comme /api/orders/1043, pour récupérer un enregistrement, sans jamais vérifier que l’utilisateur connecté a le droit d’y accéder. Remplacez l’identifiant par 1044 et vous obtenez la commande de quelqu’un d’autre. Elle relève de A01 Broken Access Control dans l’OWASP Top 10 2021, et l’OWASP API Security Top 10 désigne le même problème sous le nom de Broken Object Level Authorization (BOLA).

Exemple

Alice est connectée et consulte sa commande :

GET /api/orders/1043
Authorization: Bearer <alice-token>

Elle modifie le numéro :

GET /api/orders/1044
Authorization: Bearer <alice-token>

Si la réponse est un 200 avec l’adresse et les articles de Bob, l’endpoint authentifie bien l’utilisateur, mais n’autorise pas l’accès à cet objet précis. Des UUID difficiles à deviner compliquent la tâche mais ne corrigent pas la faille ; les identifiants fuient via les URL, les logs et les liens partagés.

Ce que vérifie un testeur

Créez deux utilisateurs de test, chacun propriétaire de ses propres données, puis utilisez les identifiants de l’utilisateur A sur les objets de l’utilisateur B pour chaque endpoint et chaque méthode : lecture, mise à jour, suppression, et routes imbriquées comme /users/{id}/invoices. C’est facile à automatiser. Avec Playwright :

import { test, expect, request } from '@playwright/test';

test("Alice cannot read Bob's order", async () => {
  const alice = await request.newContext({
    baseURL: process.env.API_URL,
    extraHTTPHeaders: { Authorization: `Bearer ${process.env.ALICE_TOKEN}` },
  });
  const res = await alice.get(`/api/orders/${process.env.BOB_ORDER_ID}`);
  expect([403, 404]).toContain(res.status());
  await alice.dispose();
});

403 et 404 sont tous deux acceptables ; beaucoup d’API renvoient 404 pour ne même pas confirmer l’existence de l’enregistrement. Vérifiez aussi :

• Les identifiants dans le corps des requêtes et dans les query strings, pas seulement dans le chemin.
• Les opérations d’écriture, où une IDOR permet de modifier ou supprimer des données.
• Les endpoints d’opérations en masse et d’export qui acceptent des listes d’identifiants.
• Les frontières entre tenants dans les systèmes multi-tenants.

Pourquoi elle passe inaperçue

Les tests fonctionnels se connectent généralement avec un seul utilisateur et utilisent ses propres données : le contrôle d’autorisation n’est donc jamais sollicité. On trouve les IDOR en se demandant, pour chaque endpoint, « et si cet identifiant appartenait à quelqu’un d’autre ? ». N’exécutez ces tests que sur des systèmes que vous êtes autorisé à tester.