L'IDOR (Insecure Direct Object Reference) e la sua versione API-centrica BOLA (Broken Object Level Authorization) sono tra le vulnerabilità più comuni e più banali: l'applicazione espone un riferimento a un oggetto (un ID nell'URL o nel corpo della richiesta) e non verifica che l'utente sia autorizzato ad accedere a quello specifico oggetto.
L'esempio da manuale: GET /api/fatture/1042 ti mostra la tua fattura. Cambi in /api/fatture/1043 e... vedi quella di qualcun altro, perché il server controlla che tu sia autenticato ma non che quella fattura sia tua. Moltiplicato per milioni di record, è una fuga di dati di massa – ed è la causa di una lunga serie di breach reali, perché è facile da sfruttare (basta cambiare un numero) e facile da introdurre (il controllo manca in un endpoint su dieci).
BOLA è la vulnerabilità n°1 della OWASP API Security Top 10 proprio per questo. Le difese, a livello di codice:
- verificare l'autorizzazione sull'oggetto specifico a ogni richiesta: non "l'utente è loggato?" ma "l'utente può accedere a questo oggetto?" – il controllo va nel codice di ogni endpoint, sistematicamente
- ID non indovinabili (UUID invece di interi sequenziali) – aiuta ma non è la difesa (è security-by-obscurity: rende più difficile l'enumerazione, non sostituisce il controllo)
- test automatici di autorizzazione (l'utente A prova ad accedere agli oggetti di B – deve fallire), parte del DAST in pipeline
È il promemoria che l'autenticazione non è autorizzazione: sapere chi sei è diverso da decidere cosa puoi toccare – e il secondo controllo è quello che tutti dimenticano. Modelli come ABAC/PBAC centralizzano proprio questa logica per non affidarla al singolo endpoint distratto.