IDOR

IDOR (Insecure Direct Object Reference, riferimento diretto e non sicuro a un oggetto) è una vulnerabilità in cui l’applicazione usa un identificatore preso dalla richiesta, come /api/orders/1043, per recuperare un record, ma non verifica mai che l’utente autenticato abbia il diritto di accedere a quel record. Cambi l’ID in 1044 e ottieni l’ordine di qualcun altro. Rientra nella categoria A01 Broken Access Control della OWASP Top 10 2021, e la OWASP API Security Top 10 chiama lo stesso problema Broken Object Level Authorization (BOLA).

Esempio

Alice ha effettuato il login e vede il suo ordine:

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

Cambia il numero:

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

Se la risposta è 200 con l’indirizzo e gli articoli di Bob, l’endpoint autentica l’utente ma non autorizza l’accesso allo specifico oggetto. UUID difficili da indovinare rendono più difficile tirare a indovinare, ma non correggono la falla: gli ID trapelano tramite URL, log e link condivisi.

Cosa verifica un tester

Crea due utenti di test, ciascuno con i propri dati, poi usa le credenziali dell’utente A sugli oggetti dell’utente B su ogni endpoint e metodo: lettura, aggiornamento, cancellazione e route annidate come /users/{id}/invoices. È facile da automatizzare. In 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();
});

Sono accettabili sia 403 sia 404; molte API restituiscono 404 per non confermare nemmeno che il record esista. Controlla anche:

• Gli ID nei body delle richieste e nelle query string, non solo nel path.
• Le operazioni di scrittura, dove un IDOR permette a un utente di modificare o cancellare dati.
• Gli endpoint di operazioni massive e di export che accettano liste di ID.
• I confini tra tenant nei sistemi multi-tenant.

Perché sfugge

I test funzionali di solito effettuano il login con un solo utente e usano i dati di quello stesso utente, quindi il controllo di autorizzazione non viene mai esercitato. Un IDOR si trova chiedendosi, per ogni endpoint, “e se questo ID appartenesse a qualcun altro?”. Esegui questi test solo su sistemi che sei autorizzato a testare.