Che cos'è l'Insecure Direct Object Reference?
L'insecure direct object reference (IDOR) è una vulnerabilità di controllo degli accessi che consente agli attaccanti di accedere ai dati appartenenti ad altri utenti manipolando gli identificatori di oggetti nelle richieste dell'applicazione. Quando l'applicazione espone direttamente agli utenti una chiave di database, un nome file o un record ID e non verifica se l'utente richiedente possiede quell'oggetto, qualsiasi utente autenticato può visualizzare o modificare i dati di un altro utente semplicemente cambiando un numero in un URL.
L'IDOR è stato responsabile di alcune delle più grandi esposizioni di dati mai registrate. Nel 2019, First American Financial Corporation ha esposto oltre 800 milioni di immagini contenenti numeri di previdenza sociale e dettagli di conti bancari perché la sua applicazione consentiva a chiunque di modificare un parametro URL per accedere a documenti appartenenti ad altri utenti.
Il fallimento principale è semplice: l'applicazione conferma che un utente è autenticato (autenticazione) ma non verifica mai se è autorizzato ad accedere a uno specifico record (autorizzazione). L'applicazione controlla la serratura della porta d'ingresso ma consente a chiunque all'interno di aprire ogni schedario.
L'IDOR corrisponde a CWE-639: Authorization Bypass Through User-Controlled Key. Nel contesto API, la stessa vulnerabilità è chiamata Broken Object Level Authorization, o BOLA, che occupa la posizione #1 nella OWASP API1 (API1:2023). La sua categoria madre, Broken Access Control, è al #1 nella OWASP Top 10 e mantiene quella posizione nell' edizione 2025.
Prima di esaminare la meccanica, è utile comprendere le diverse forme che può assumere l'IDOR e dove si colloca nei framework di vulnerabilità consolidati.
Tipi di Insecure Direct Object Reference
L'IDOR non è un difetto uniforme. Si manifesta in modo diverso a seconda della relazione di privilegio coinvolta e del tipo di oggetto esposto.
IDOR orizzontale
La forma più comune. Un utente autenticato accede a oggetti appartenenti a un pari con lo stesso livello di privilegio, ad esempio cambiando /api/users/123/profile in /api/users/124/profile per leggere i dati di un altro account. Non avviene alcuna elevazione di privilegio; l'attaccante semplicemente attraversa i confini degli account all'interno dello stesso livello.
IDOR verticale
L'attaccante accede a oggetti che richiedono privilegi superiori rispetto a quelli posseduti: raggiungendo un record amministrativo, un endpoint di configurazione riservato endpoint o una funzione di gestione manipolando un identificatore. L'IDOR verticale spesso si concatena in una completa escalation di privilegi, come nel caso Honda eCommerce dove un ricercatore è passato dall'accesso a livello dealer a quello di amministratore della piattaforma.
IDOR API (BOLA)
Nelle API REST e GraphQL, lo stesso difetto assume un nome distinto: Broken Object Level Authorization (BOLA). La natura stateless delle API rende questa variante particolarmente diffusa. Un singolo resolver o route handler mal configurato può esporre ogni record di una collezione a qualsiasi sessione autenticata.
IDOR su risorse statiche
Download di file, esportazioni ed endpoint di report vengono spesso trascurati durante le revisioni di autorizzazione. Se un'applicazione serve un PDF a /reports/invoice_1042.pdf senza verificare che l'utente richiedente possieda quella fattura, la vulnerabilità è strutturalmente identica a un IDOR su record di database. Questa variante è comune in ambito sanitario, finanziario e legale dove i documenti contengono dati regolamentati.
Ognuna di queste forme corrisponde a una posizione distinta nei framework di vulnerabilità consolidati, ed è qui che la classificazione dell'IDOR si complica.
Classificazione OWASP dell'Insecure Direct Object Reference
L'IDOR appare in tre diversi framework di vulnerabilità, ognuno dei quali riflette una diversa prospettiva organizzativa sullo stesso errore di fondo.
| Framework | Voce | Nome | Posizione attuale |
| OWASP Top 10 (2007–2013) | A4 | Insecure Direct Object References | Voce autonoma; deprecata come voce separata |
| OWASP Top 10 (2021–2025) | A01 | Broken Access Control | #1 (mappa 40 CWE, incluso CWE-639) |
| OWASP API Security Top 10 | API1:2023 | Broken Object Level Authorization (BOLA) | #1 (Sfruttabilità facile, Diffusione ampia) |
| MITRE CWE | CWE-639 | Authorization Bypass Through User-Controlled Key | 2025 CWE Top 25 |
Posizionamento nell'OWASP Top 10
L'IDOR è stato una voce autonoma nella Top 10 dal 2007 al 2013. Nel 2017 OWASP lo ha consolidato sotto Broken Access Control, che è salito al #1 nel 2021 e mantiene quella posizione nell'edizione 2025, mappando ora 40 CWE sotto la categoria.
OWASP API Security Top 10
BOLA, la declinazione API-specifica dell'IDOR, occupa la posizione API1 da quando l'API Security Top 10 è stata lanciata nel 2019. La voce API1:2023 valuta BOLA con il massimo punteggio sia per sfruttabilità ("Facile") sia per diffusione ("Ampia"), motivo per cui genera costantemente più segnalazioni rispetto a qualsiasi altra classe di vulnerabilità API.
Mappatura CWE
CWE-639 (Authorization Bypass Through User-Controlled Key) è la classificazione MITRE primaria dell'IDOR. La sua categoria madre è CWE-284 (Improper Access Control). Il figlio più specifico per implementazioni basate su SQL è CWE-566 (Authorization Bypass Through User-Controlled SQL Primary Key). CWE-639 appare nella 2025 CWE Top 25.
Comprendere la tassonomia prepara il terreno per esaminare come l'exploit funziona concretamente nella pratica.
Come funziona l'Insecure Direct Object Reference?
L'IDOR sfrutta una lacuna fondamentale tra ciò che l'applicazione autentica e ciò che autorizza. I passaggi seguenti illustrano come un singolo identificatore esposto possa diventare una violazione di dati su larga scala.
Fase 1: L'applicazione espone un riferimento diretto a un oggetto
L'applicazione genera un URL o un parametro API che mappa direttamente a un oggetto interno:
Il valore 123 è la chiave primaria di database per un record utente, esposta direttamente nel percorso URL.
Fase 2: L'attaccante modifica l'identificatore
Un attaccante cambia 123 in 124. Se l'applicazione restituisce i dati del profilo dell'utente 124, la vulnerabilità è confermata.
Fase 3: Il server recupera l'oggetto senza un controllo di autorizzazione
La documentazione OWASP fornisce un chiaro pattern di codice vulnerabile
Il decoratore @login_required conferma che l'utente è autenticato. Non verifica se l'utente 123 debba accedere al profilo dell'utente 124. Aggiungere una riga risolve la vulnerabilità:
Fase 4: Lo sfruttamento si espande tramite enumerazione
Una volta che un attaccante conferma che il pattern funziona, scrive uno script per iterare tra i possibili valori ID, trasformando una singola vulnerabilità in una violazione di dati di massa. A seconda dell'applicazione, questa enumerazione può completarsi rapidamente. La velocità dello sfruttamento è ciò che trasforma un singolo difetto di controllo accessi in una violazione di dati su larga scala.
Quattro principali superfici di attacco
| Superficie | Esempio |
| Parametri nel percorso URL | /invoices/1042 cambiato in /invoices/1043 |
| Parametri nella query string | ?order_id=7001 cambiato in ?order_id=7002 |
| Parametri file | ?file=report_user1.pdf cambiato in ?file=report_user2.pdf |
| Campi nascosti nel body POST | user_id in una sottomissione di form cambiato con l'ID di un altro utente |
Queste superfici di attacco esistono a causa di cause strutturali più profonde nel modo in cui le applicazioni sono progettate e sviluppate.
Cause dell'Insecure Direct Object Reference
L'IDOR deriva da decisioni di progettazione strutturale e da comuni fraintendimenti degli sviluppatori che si accumulano nelle architetture applicative.
Autorizzazione mancante e query non scoperte
La causa principale sono le applicazioni che utilizzano input forniti dall'utente per recuperare oggetti senza verificare che l'utente richiedente possieda il record. Questo si manifesta più comunemente come query di database non scoperte: applicazioni che interrogano l'intera tabella degli oggetti (Order.find(order_id)) invece del dataset dell'utente autenticato (current_user.orders.find(order_id)), esponendo tutti i record a qualsiasi sessione autenticata.
Identificatori prevedibili ed esposizione diretta delle chiavi
MITRE CWE-639 lo identifica esplicitamente: i sistemi che utilizzano ID di record sequenziali o facilmente indovinabili consentono agli attaccanti di enumerare i dati di altri utenti incrementando i valori. Esporre chiavi primarie di database direttamente in URL o body POST, in particolare sequenze di interi (1, 2, 3…), crea una superficie di attacco facilmente prevedibile.
Il fraintendimento sugli UUID
L' OWASP cheat sheet lo affronta direttamente: identificatori complessi come GUID rendono praticamente impossibile indovinare valori validi, ma i controlli di accesso restano essenziali. Se gli attaccanti ottengono URL validi tramite link condivisi o risposte dell'applicazione, l'applicazione deve comunque bloccare l'accesso non autorizzato.
Architettura API stateless
OWASP API1:2023 identifica una causa strutturale specifica per le API: il server si affida a parametri come gli ID oggetto inviati dal client per decidere quali oggetti accedere. Le API REST e GraphQL sono strutturalmente predisposte all'IDOR senza una logica di autorizzazione esplicita per ogni richiesta.
Quando queste cause non vengono affrontate, le vulnerabilità risultanti generano impatti aziendali che vanno ben oltre il livello tecnico.
Impatto e rischio dell'Insecure Direct Object Reference
L'impatto dell'IDOR va dalla divulgazione di dati fino al takeover dell'account completo, con conseguenze che si estendono a livello normativo, finanziario e di sicurezza.
Esposizione di dati su larga scala
Poiché lo sfruttamento dell'IDOR è automatizzabile, un singolo endpoint vulnerabile può esporre un intero database. L'IDOR di First American ha esposto oltre 800 milioni di immagini. Optus ha perso record di clienti tramite un endpoint API dimenticato con controlli di accesso compromessi.
Sanzioni normative e finanziarie
Le violazioni IDOR innescano azioni normative pluriennali. First American ha ricevuto sanzioni da parte di SEC e NYDFS. Anche Optus ha subito gravi conseguenze finanziarie.
Takeover account ed escalation di privilegi
L'IDOR non si limita alla lettura dei dati. In un caso documentato sulla piattaforma eCommerce di Honda, un ricercatore ha avuto accesso a tutti i record dei dealer cambiando un singolo valore ID ed è poi passato a ruolo di amministratore della piattaforma, riservato ai dipendenti Honda.
Valutazioni di gravità OWASP
L' OWASP API Top 10 valuta BOLA con "Facile" sfruttabilità e "Ampia" diffusione. La combinazione di sfruttamento semplice e ampia diffusione è il motivo per cui mantiene la posizione #1.
Queste valutazioni di gravità riflettono i metodi utilizzati dagli attaccanti per sfruttare l'IDOR su larga scala.
Come gli attaccanti sfruttano l'Insecure Direct Object Reference
Lo sfruttamento dell'IDOR segue un workflow strutturato che richiede una competenza tecnica minima.
Sostituzione di parametri
L'attaccante modifica un identificatore con il valore di un altro utente e osserva la risposta. Cambiare /api/users/123/profile in /api/users/124/profile e ricevere una risposta 200 OK invece di 403 Forbidden conferma la vulnerabilità.
Enumerazione automatizzata
Una volta confermata, gli attaccanti scalano l'exploit utilizzando il modulo Intruder di Burp Suite, OWASP ZAP o script personalizzati per iterare su tutti i possibili valori ID. La documentazione OWASP API descrive come uno script semplice che manipola gli ID in un URL consenta l'accesso a migliaia di record.
Sfruttamento concatenato
Gli attaccanti combinano l'IDOR con altre vulnerabilità. Il caso Honda eCommerce dimostra l'accesso orizzontale ai dati concatenato con l'escalation verticale dei privilegi. La piattaforma McDonald's McHire ha combinato un IDOR con credenziali di default, aggravando l'esposizione.
Accesso orizzontale e verticale
La guida OWASP sul controllo accessi chiarisce la distinzione. L'IDOR consente più comunemente l'escalation orizzontale dei privilegi: l'utente A accede ai dati dell'utente B allo stesso livello di privilegio. Più raramente, l'IDOR consente l'escalation verticale: un utente standard ottiene accesso da amministratore.
La semplicità di queste tecniche significa che praticamente qualsiasi applicazione che gestisce dati utente può diventare un bersaglio.
Chi è interessato dall'Insecure Direct Object Reference?
L'IDOR interessa qualsiasi applicazione che utilizza identificatori controllabili dall'utente per accedere a oggetti senza controlli di autorizzazione per richiesta.
Architetture applicative ad alto rischio
Il rischio IDOR è amplificato da alcuni pattern strutturali che espongono i riferimenti agli oggetti più ampiamente o rendono più facile saltare i controlli di autorizzazione.
- API REST con pattern URL basati su risorse. Qualsiasi API che segue la convenzione
/resource/{id}ha un'esposizione strutturale all'IDOR per design. - API GraphQL. L'accesso agli oggetti tramite argomenti crea la stessa vulnerabilità quando i resolver saltano i controlli di proprietà.
- Applicazioni SaaS multi-tenant. Un utente in un tenant manipola gli ID per accedere ai dati di un altro tenant.
- Backend API per IoT e mobile. Flussi di autenticazione complessi e gestione limitata dello stato lato server aumentano l'esposizione BOLA.
- Piattaforme e-commerce. Order ID, invoice ID e riferimenti agli account cliente sono obiettivi di alto valore.
Ciò che accomuna tutte queste architetture è che l'accesso agli oggetti è guidato da identificatori controllati dal client, con il server che non esegue alcun controllo di proprietà prima di restituire i dati.
Settori ad alto rischio
I settori più esposti sono quelli in cui i riferimenti agli oggetti mappano direttamente a record sensibili, dati regolamentati o sistemi fisici.
- Sanità: CVE-2024-28320 (Hospital Management System, CVSS 7.6) ha consentito la lettura e modifica di dati paziente.
- Servizi finanziari: Le piattaforme di pagamento e le società di titoli affrontano sia l'esposizione dei dati sia il rischio normativo.
- Pubblica amministrazione: Secondo HackerOne, i programmi governativi segnalano l'IDOR come problema ricorrente.
- Automotive: I casi Pandora/Viper e CVE-2025-11690 confermano il rischio reale per i sistemi veicolari.
Le violazioni documentate in questi settori illustrano le conseguenze reali di lasciare l'IDOR irrisolto.
Esempi reali di Insecure Direct Object Reference
I seguenti casi mostrano come l'IDOR si sia manifestato in diversi settori e tipologie applicative. Ogni incidente risale allo stesso errore di fondo: identificatori forniti dall'utente che raggiungono un server che non verifica mai se il richiedente possiede l'oggetto restituito.
First American Financial Corporation (2019)
L'applicazione EaglePro di First American consentiva a qualsiasi utente di modificare un parametro URL e accedere a documenti escrow e titoli appartenenti ad altri utenti. La vulnerabilità, introdotta nel 2014, è rimasta per cinque anni. Sono state esposte oltre 800 milioni di immagini, inclusi numeri di previdenza sociale e documenti di pagamento mutuo. Le sanzioni normative sono documentate nella documentazione SEC e nella documentazione NYDFS. CISA, NSA e l'Australian Signals Directorate hanno citato questo caso nella loro advisory congiunta sull'IDOR.
Violazione dati Optus (2022)
Un errore di codifica del 2018 ha compromesso i controlli di accesso su un endpoint API di Optus. Optus ha corretto l'errore sul dominio principale nel 2021 ma ha lasciato un dominio dimenticato e accessibile da Internet non patchato. Nel settembre 2022, un attaccante ha sfruttato il controllo di accesso compromesso per esfiltrare record di clienti, inclusi numeri di identificazione personale validi. L'Australian Communications and Media Authority (ACMA) ha confermato che l'attacco "non era altamente sofisticato" ed è stato eseguito tramite "un semplice processo di tentativi ed errori." Rimane la più grande violazione di dati in Australia.
Chatbot McDonald's McHire (2025)
I ricercatori di sicurezza Ian Carroll e Sam Curry hanno scoperto un IDOR nell'API del chatbot Paradox.ai McHire utilizzato da McDonald's. Decrementando un intero lead_id nell'endpoint interno /api/lead/cem-xhr, hanno recuperato trascrizioni chat complete, dettagli di contatto e token di sessione appartenenti ad altri candidati senza alcun controllo di autorizzazione. Il lead_id della loro applicazione era 64.185.742, indicando la scala dei record potenzialmente accessibili. La vulnerabilità è stata divulgata il 30 giugno 2025 e corretta lo stesso giorno.
Pandora e Viper Smart Car Alarms (2019)
Pen Test Partners ha trovato vulnerabilità IDOR nelle API di allarmi auto smart che consentivano il takeover completo degli account su intere flotte di veicoli. Gli attaccanti potevano cambiare password o indirizzi email degli account, ottenendo il controllo fisico dei veicoli. I ricercatori hanno stimato che circa tre milioni di veicoli di fascia alta sono stati esposti prima che i vendor correggessero i difetti entro pochi giorni dalla divulgazione.
Segnale dai bug bounty
L'IDOR è una segnalazione di alto valore costante sulle piattaforme di bug bounty. Una segnalazione PayPal ha ottenuto un bounty significativo su HackerOne, e i dati HackerOne mostrano che l'IDOR resta una classe di vulnerabilità ricorrente.
Questi incidenti ripercorrono oltre un decennio di presenza dell'IDOR nei principali framework di vulnerabilità e nelle violazioni reali.
Timeline e storia dell'Insecure Direct Object Reference
L'IDOR fa parte del panorama formale della sicurezza da quasi due decenni. La timeline seguente ne traccia l'evoluzione da categoria autonoma a concetto fondamentale integrato in più framework, e la sua continua espansione in infrastrutture più recenti come API, IoT e sistemi AI.
| Periodo | Traguardo |
| 2007 | OWASP introduce il termine "IDOR" nella Top Ten come categoria autonoma in A4. |
| 2013-2014 | Ultimo anno come categoria autonoma OWASP (A4). Difetto IDOR di First American introdotto |
| 2017 | L'IDOR viene consolidato in Broken Access Control in A5. |
| 2019 | OWASP API Security Top 10 introduce BOLA come API1. Disclosure First American. Documentata esposizione Pandora/Viper. |
| 2021 | Broken Access Control al #1 nella OWASP Top 10. |
| 2022 | Violazione Optus, la più grande violazione di dati australiana. |
| 2023 | CISA/NSA/ACSC pubblicano advisory congiunta AA23-208A sull'IDOR. BOLA confermato in API1:2023. |
| 2025 | Broken Access Control confermato al #1, mappando 40 CWE. CWE-639 elencato nella 2025 CWE Top 25. Disclosure IDOR McDonald's McHire da Ian Carroll e Sam Curry. |
| 2024-2026 | L'IDOR si espande in infrastrutture AI/LLM (CVE-2025-4962), telematica veicolare (CVE-2025-11690) e IAM aziendale (CVE-2024-56404). HackerOne conferma che le segnalazioni IDOR sono in aumento mentre XSS e SQLi sono in calo. |
Con la persistenza dell'IDOR in quasi due decenni di tracciamento delle vulnerabilità, sono necessari metodi affidabili per individuarlo nelle proprie applicazioni.
Come rilevare l'Insecure Direct Object Reference
L'IDOR è difficile da individuare solo con strumenti perché richiede di ragionare sulla proprietà degli oggetti e sulla logica di business, non solo sul pattern matching dei codici di risposta.
Penetration test manuale (obbligatorio)
L' OWASP WSTG definisce la procedura di test:
- Mappare tutte le posizioni in cui l'input utente fa riferimento direttamente a oggetti.
- Modificare il valore del parametro utilizzato per referenziare gli oggetti.
- Valutare se è possibile recuperare oggetti appartenenti ad altri utenti o bypassare l'autorizzazione.
- Testare diversi metodi HTTP e pattern di accesso bulk.
Il test manuale è l'unico metodo che ragiona sull'intento di autorizzazione invece che sulla sola manipolazione dei parametri. Nessuno scanner può sostituire in modo affidabile un tester che comprende cosa ogni ruolo utente dovrebbe o non dovrebbe poter accedere.
Strumenti di Application Security Testing
Gli strumenti DAST come OWASP ZAP e Burp Suite possono trovare l'IDOR se configurati con account di test multi-utente e mapping di ID oggetto cross-utente. Le configurazioni di default degli scanner non rileveranno l'IDOR. Gli strumenti SAST possono segnalare endpoint privi di chiamate alle funzioni di autorizzazione ma non possono determinare se la logica di autorizzazione sia semanticamente corretta a runtime.
Monitoraggio comportamentale a runtime
Questo è l'unico controllo in produzione che può realisticamente individuare l'IDOR in produzione. Cercare questi segnali:
- Richieste sequenziali o con pattern di enumerazione verso endpoint di riferimento oggetto da una singola sessione
- Richieste autenticate che restituiscono 200 OK per ID oggetto non appartenenti all'utente richiedente
- Richieste ad alto volume di riferimento oggetto su più account utente
A differenza dei test pre-deployment, il monitoraggio comportamentale funziona continuamente in produzione, dove avviene lo sfruttamento reale. È l'unico controllo che può rilevare l'IDOR mentre viene attivamente abusato su dati reali.
Revisione sicura del codice
Secondo l' Authorization cheat sheet, la code review deve verificare che il permesso sia validato su ogni richiesta e che il controllo accessi sia implementato globalmente e non per singolo metodo. Prestare particolare attenzione agli endpoint che accettano identificatori forniti dall'utente e tracciare il percorso del codice dall'acquisizione del parametro alla query di database fino alla risposta. Qualsiasi percorso che recupera un oggetto senza limitare la query ai permessi dell'utente autenticato rappresenta un rischio IDOR confermato.
Individuare l'IDOR è solo il primo passo. Prevenirlo richiede controlli integrati in tutto il ciclo di sviluppo e deployment.
Come prevenire l'Insecure Direct Object Reference
La prevenzione richiede un approccio stratificato che copra progettazione, sviluppo, test e monitoraggio a runtime.
Fase di progettazione: modellare l'autorizzazione in ogni funzionalità
Rendere il controllo accessi compromesso parte dell' analisi della superficie di attacco durante la progettazione delle funzionalità. Definire funzioni di autorizzazione esplicite (pattern canAccess, isOwner) prima di scrivere codice.
Fase di sviluppo: applicare l'autorizzazione lato server su ogni accesso oggetto
L' IDOR cheat sheet specifica questi controlli:
- Implementare controlli di accesso per ogni oggetto che un utente tenta di accedere. Determinare l'utente autenticato dalle informazioni di sessione, non da identificatori forniti dal client. Applicare i controlli tramite middleware centralizzato invece che tramite logica per singolo metodo.
- Limitare le query di database al dataset accessibile dall'utente autenticato:
Utilizzare mappe di riferimento indirette che traducono valori esterni offuscati in ID di database interni, combinati con controlli di autorizzazione.
Adottare UUID o valori casuali lunghi come identificatori pubblici. Questo è un livello di difesa in profondità, non un controllo primario.
Evitare la cifratura degli identificatori. L'OWASP Cheat Sheet afferma che "può essere difficile da implementare in modo sicuro."
- Applicare l'autorizzazione sulle risorse statiche, una superficie spesso trascurata secondo l' authorization cheat sheet.
Questi controlli funzionano perché applicano la proprietà a livello di dati invece di fidarsi dei valori forniti dal client. Un attaccante che manipola un parametro incontra un controllo di autorizzazione invece di una query riuscita.
Fase di test: test di autorizzazione multi-utente
Eseguire scansioni DAST con configurazioni multi-utente che testano l'accesso cross-account. Includere regole SAST che segnalano endpoint privi di chiamate alle funzioni di autorizzazione. Dare priorità al penetration testing manuale per IDOR di logica di business.
Fase di runtime: monitoraggio comportamentale API
Implementare monitoraggio comportamentale che stabilisce una baseline dei pattern di accesso API normali e segnala accessi anomali agli oggetti. La tecnologia Storyline di SentinelOne può ricostruire l'intera sequenza di interazioni API e il contesto identitario attorno a pattern di accesso sospetti, fornendo al team la timeline forense necessaria per confermare o escludere lo sfruttamento IDOR.
L'implementazione efficace di questi controlli richiede la giusta combinazione di strumenti di application security testing e monitoraggio a runtime.
Strumenti per rilevamento e prevenzione
Nessuno strumento copre completamente l'IDOR. Una copertura efficace richiede una combinazione stratificata di scanning in fase di sviluppo, monitoraggio a runtime e validazione manuale lungo tutto il ciclo di vita applicativo. Gli strumenti seguenti coprono diverse fasi, ciascuno con copertura e limiti distinti.
Strumenti di Application Security Testing
| Tipo di strumento | Capacità | Copertura IDOR | Limitazione |
| DAST (OWASP ZAP, Burp Suite) | Testa applicazioni in esecuzione via HTTP/S | Trova IDOR con configurazioni multi-utente | Richiede setup manuale di scenari di test cross-account |
| SAST (SonarQube, Checkmarx) | Analisi white-box del codice sorgente | Segnala pattern di chiamate di autorizzazione mancanti | Non può verificare la correttezza semantica della logica di autorizzazione |
| IAST (Contrast Security) | Agente in-app durante i test QA | Contesto comportamentale a runtime con meno falsi positivi | Richiede ambienti di test strumentati |
| Pen test manuale | Logica di business, scenari multi-utente | Unico metodo affidabile per IDOR complessi | Richiede tempo, necessita tester esperti |
Sicurezza API e monitoraggio comportamentale
Gli strumenti di monitoraggio comportamentale API costruiscono baseline dei pattern di accesso normali e segnalano anomalie. Questi sono gli unici controlli a runtime che possono realisticamente individuare lo sfruttamento IDOR in produzione, perché le richieste IDOR sono sintatticamente identiche al traffico legittimo.
Vulnerabilità correlate
L'IDOR appartiene alla più ampia famiglia Broken Access Control. Comprendere le sue relazioni con altri tipi di vulnerabilità correlate aiuta a prioritizzare la remediation.
- Broken Object Level Authorization (BOLA), API1:2023. Sia IDOR che BOLA mappano a CWE-639. BOLA è la declinazione API-specifica dello stesso errore di fondo.
- Broken Function Level Authorization (BFLA), API5:2023 / CWE-285. Mentre l'IDOR prende di mira gli oggetti dati (quali record puoi accedere), il BFLA prende di mira le funzioni API (quali operazioni puoi eseguire), abilitando principalmente l'escalation verticale dei privilegi.
- Forced Browsing (CWE-425). Bypassa i controlli di navigazione e di pagina per accedere direttamente a pagine riservate, elencato come esempio concreto di Broken Access Control.
- SQL Primary Key Authorization Bypass (CWE-566). Figlio diretto di CWE-639, è il CWE più specifico per implementazioni IDOR basate su SQL.
- Escalation verticale dei privilegi (CWE-269 / CWE-285). L'IDOR può concatenarsi in una escalation di privilegi quando un attaccante modifica un identificatore per accedere a funzioni amministrative, come dimostrato nel caso Honda eCommerce.
Diversi CVE specifici dimostrano come questi pattern di vulnerabilità correlati si manifestano nei sistemi in produzione.
CVE correlati
| ID CVE | Descrizione | Gravità | Prodotto interessato | Anno |
| CWE-639 IDOR nei moduli API tab-doc di Tableau Server; un attaccante sulla rete adiacente manipola chiavi controllate dall'utente per bypassare l'autorizzazione e accedere ai cluster di database di produzione | ALTA | Salesforce Tableau Server (<2025.1.3) | 2025 | |
| CWE-639 IDOR nel comando tabdoc set-initial-sql di Tableau Server; utenti autenticati a basso privilegio manipolano parametri controllati dall'utente per accedere ai cluster di database di produzione | ALTA | Salesforce Tableau Server (<2025.1.3) | 2025 | |
| CWE-639 IDOR nella gestione delle risorse thread di Chainlit; utenti autenticati forniscono l'ID thread di un altro utente per accedere ai dati di conversazione senza verifica della proprietà | MEDIA | Chainlit | 2025 | |
| CWE-639 IDOR nel plugin WordPress Five Star Restaurant Reservations; attaccanti non autenticati manipolano identificatori di prenotazione per accedere, modificare o eliminare record appartenenti ad altri utenti | MEDIA | Five Star Restaurant Reservations WP plugin (≤2.7.8) | 2025 | |
| IDOR in One Identity Identity Manager consente escalation di privilegi in installazioni on-premise; l'attaccante manipola riferimenti oggetto per assumere permessi oltre il proprio ruolo assegnato | CRITICA | One Identity Identity Manager 9.x (<9.3) | 2024 | |
| IDOR non autenticato nello strumento SO Planning; quando la visualizzazione pubblica è abilitata, un attaccante accede all'intero database sottostante richiedendo direttamente l'endpoint di esportazione, scaricandolo come CSV | CRITICA | SO Planning (<1.52.02) | 2024 | |
| IDOR non autenticato nel plugin WooCommerce Stripe Payment Gateway; la mancata verifica della proprietà dell'ordine espone nome di fatturazione, email e indirizzo di qualsiasi ordine a utenti non autenticati su oltre 900.000 installazioni attive | ALTA | WooCommerce Stripe Payment Gateway WP plugin (≤7.4.0) | 2023 | |
| CWE-639 IDOR nella piattaforma di imaging medico ExtremePacs Extreme XDS; la manipolazione di chiavi controllate dall'utente consente l'accesso a record di imaging di altri pazienti senza autorizzazione | ALTA | ExtremePacs Extreme XDS (<3914) | 2023 | |
| IDOR nel backend server condiviso di stalkerware ha esposto messaggi di testo, registri chiamate, foto e dati di geolocalizzazione da centinaia di migliaia di dispositivi; citato per nome nell'advisory CISA/NSA/ACSC AA23-208A | ALTA | 1byte / Multiple stalkerware apps | 2022 | |
| IDOR nella funzione di reset password di Telos Alliance Omnia MPX Node; l'attaccante fornisce l'identificatore account di qualsiasi utente per reimpostare la password, consentendo il takeover completo dell'account inclusi gli account Administrator | ALTA | Telos Alliance Omnia MPX Node (1.0.0–1.4.x) | 2022 |
Liberate la cybersicurezza alimentata dall'intelligenza artificiale
Elevate la vostra posizione di sicurezza con il rilevamento in tempo reale, la risposta automatica e la visibilità totale dell'intero ambiente digitale.
Richiedi una demoConclusione
L'insecure direct object reference rimane uno dei fallimenti di sicurezza web più sfruttati perché compromette l'autorizzazione a livello di oggetto, non solo la gestione degli input. Se l'applicazione si fida degli identificatori forniti dall'utente senza verificarne la proprietà, una piccola modifica all'URL può diventare un'esposizione di dati su larga scala.
Riduci questo rischio applicando l'autorizzazione su ogni accesso agli oggetti, testando su più contesti utente e monitorando gli abusi in produzione.
Domande frequenti
L'IDOR è un errore nell'applicazione dell'appartenenza ai record. Se il server non verifica che un utente possa accedere a uno specifico oggetto, la modifica di un nome file, numero d'ordine o ID profilo può esporre o alterare i dati di altri utenti. In pratica, l'IDOR è prima di tutto un problema di autorizzazione e solo in secondo luogo un problema di manipolazione dei parametri.
Sì. I materiali OWASP più datati possono chiamarla IDOR, mentre le linee guida più recenti la includono in Broken Access Control. I team focalizzati sulle API spesso chiamano lo stesso errore BOLA.
Etichette diverse indicano la stessa causa principale: assenza di autorizzazione a livello di oggetto.
Sì. Un attaccante di solito ha bisogno solo di un endpoint raggiungibile e di un modo valido per inviare richieste. Tipicamente non sono necessari esecuzione di codice o distribuzione di malware.
Una volta che uno schema di riferimento oggetto funziona, lo sfruttamento può espandersi tramite richieste automatizzate, motivo per cui domini dimenticati, vecchie versioni API e backend mobili esposti sono particolarmente rischiosi.
Le applicazioni sono più vulnerabili quando la ricerca degli oggetti è guidata dall'input del client. Il rischio aumenta nei sistemi che espongono molti riferimenti a oggetti, condividono infrastrutture tra tenant o dipendono da API stateless che si fidano ripetutamente degli ID inviati dal client. Operazioni di alto valore includono il recupero, l'aggiornamento, l'esportazione o l'eliminazione di record collegati agli utenti.
Gli attaccanti di solito iniziano dove l'applicazione rivela come nomina gli oggetti: un ID visibile in un URL, un campo nascosto in un form, un body JSON o una risposta API. Successivamente scambiano i valori, confrontano le risposte e testano diversi metodi o contesti di account.
Anche piccole differenze nei codici di stato, nelle dimensioni delle risposte o nei campi restituiti possono confermare l'accesso sfruttabile agli oggetti.
I primi segnali sono solitamente comportamentali. Occorre monitorare un'identità autenticata che richiede molti ID oggetto, attraversa i confini previsti di account o tenant, o accede a record in una sequenza che non corrisponde al comportamento normale degli utenti.
Poiché l'IDOR spesso si nasconde all'interno di traffico HTTP altrimenti valido, il contesto è più importante della sintassi.
La sua gravità deriva tanto dalla scala e affidabilità quanto dal puro CVSS. Molte vulnerabilità richiedono catene di exploit fragili; l'IDOR spesso funziona con il normale comportamento applicativo una volta che manca il controllo di proprietà.
Può variare da una limitata perdita di dati fino alla compromissione dell'account o all'elevazione dei privilegi, a seconda dell'oggetto esposto.
A volte. Se l'oggetto esposto controlla il reset delle password, le impostazioni amministrative, i confini dei tenant o le azioni di workflow, l'IDOR può diventare il primo passo di una compromissione più ampia.
La funzione aziendale dell'oggetto determina se la vulnerabilità resta locale a un record o si espande in un incidente a livello di piattaforma.
Non di default. Gli strumenti possono trovare input e ripetere richieste, ma l'IDOR richiede di capire chi dovrebbe possedere quale oggetto e come i ruoli differiscono tra le sessioni.
L'approccio più efficace combina automazione con dati di test multiutente preparati e validazione manuale. In produzione, il monitoraggio comportamentale è più realistico che affidarsi solo agli scanner.
I settori a maggior rischio sono quelli in cui i riferimenti agli oggetti corrispondono direttamente a record sensibili, dati regolamentati o effetti nel mondo fisico. In pratica, ciò include cartelle sanitarie, documenti finanziari, dati governativi, sistemi automotive e asset di gestione delle identità.
In questi ambienti, ogni accesso non autorizzato a un oggetto può comportare gravi conseguenze in termini di privacy, conformità, frode o sicurezza.
