Un quindicenne, un IDOR, undici milioni di francesi

Il 15 aprile 2026 l'Agence nationale des titres sécurisés — l'agenzia del Ministero dell'Interno francese che emette carte d'identità, passaporti, patenti e permessi di soggiorno — ha rilevato un'intrusione nel proprio portale. Cinque giorni dopo, l'annuncio pubblico. Il 25 aprile la polizia ha fermato a Parigi un quindicenne. Il 30 aprile è stato formalmente incriminato. L'agenzia, nel frattempo, è stata rinominata France Titres.

I numeri sono in disputa. La comunicazione ufficiale parla di 11,7 milioni di account compromessi. L'attaccante, sui forum criminali dove ha tentato la vendita del dump, ne ha rivendicati tra 12 e 18 milioni. Il forensic è ancora in corso, e CNIL, ANSSI e Procura di Parigi sono tutti coinvolti.

Il vettore tecnico è un classico così classico da essere imbarazzante: un IDOR nell'API di gestione dei documenti. Più fonti riportano che l'attaccante stesso, sui forum dove ha messo in vendita il dump, lo avrebbe definito "really stupid".

Cosa significa IDOR

IDOR è l'acronimo di Insecure Direct Object Reference — riferimento diretto e non sicuro a un oggetto. Tradotto in pratica: un'API espone risorse identificate da un parametro (tipicamente un numero o un identificatore prevedibile), e non verifica se chi sta facendo la richiesta è davvero autorizzato a vedere proprio quella risorsa.

Esempio elementare. Un utente autenticato chiama l'endpoint:

GET /api/citizen/12345/document

e riceve i propri dati. Se l'API ha un IDOR, sostituendo 12345 con 12346 riceverà i dati di un altro cittadino. Il sistema sa che chi chiama è autenticato — il token è valido — ma non controlla che la risorsa richiesta sia di sua competenza. L'authentication c'è. L'authorization a livello di oggetto manca.

Nella tassonomia OWASP API Security Top 10, questa categoria si chiama BOLA — Broken Object Level Authorization. È al primo posto della classifica dal 2019, edizione dopo edizione. Non perché sia esotica: perché è ovunque.

Perché un controllo così banale continua a saltare

Tre ragioni strutturali.

Primo, i WAF non lo intercettano. Una richiesta IDOR è sintatticamente perfetta: token valido, endpoint legittimo, parametro nel formato atteso. Per un firewall applicativo è traffico normale.

Secondo, i test automatici lo trovano male. Gli scanner di vulnerabilità sanno cercare SQL injection, XSS, path traversal — pattern noti. L'IDOR richiede di conoscere il modello dei dati e la logica di proprietà delle risorse. È un test che si scrive caso per caso, su ogni endpoint.

Terzo, il codice "sembra giusto". In code review, una funzione che recupera getDocument(id) da un database appare innocua. Il bug non è in cosa fa, è in cosa non fa prima: il check if document.owner_id != current_user.id: raise Forbidden. La sua assenza è invisibile a chi rilegge.

Il risultato è che IDOR/BOLA arriva in produzione attraversando indenne i livelli di difesa che le organizzazioni pensano di avere.

La regola operativa

C'è un solo principio che chiude il problema: l'authorization deve essere per-oggetto, non per-endpoint.

Non è sufficiente proteggere la rotta (/api/citizen/* richiede autenticazione). Per ogni singola risorsa restituita, il backend deve verificare la relazione fra l'utente autenticato e la risorsa richiesta. Concretamente:

• A livello di codice: middleware o decoratori che applicano il check di ownership/role in modo sistematico, non lasciato alla disciplina dello sviluppatore.
• A livello di test: per ogni endpoint che restituisce dati di un utente, almeno un test negativo che simula l'utente A che richiede la risorsa di B e verifica il 403.
• A livello di pen test: richiedere esplicitamente in scope la verifica BOLA su tutti gli endpoint identitari, non solo i "soliti sospetti".

Pattern come gli identificatori opachi (UUID al posto di interi sequenziali) alzano la barriera, ma non risolvono. Un UUID rallenta l'enumerazione bruteforce, non l'attaccante che già conosce l'ID di un altro oggetto.

La lezione che riguarda anche chi non gestisce passaporti

C'è la tentazione, leggendo questa notizia, di archiviarla come "problema della PA francese". È un errore di prospettiva.

Il dato più rilevante non è la dimensione del breach. È il profilo dell'attaccante. Non un APT statale, non un gruppo organizzato: un ragazzino con accesso a un browser e curiosità sufficiente per modificare un parametro in una URL. L'asticella tecnica richiesta per bucare un'agenzia governativa europea era così bassa da essere alla portata di un autodidatta minorenne.

Per chi sviluppa o gestisce API in una PMI questo è un segnale operativo molto preciso: la maturità di sicurezza media nell'ecosistema è bassa abbastanza che non serve un avversario sofisticato per essere bersaglio. Serve un'API esposta con BOLA, e la prossima persona che ci passa sopra.

Il perimetro non è più il firewall. È ogni singolo endpoint che restituisce un oggetto.

Trattarlo con disciplina non è una scelta avanzata. È il livello di base sotto il quale, oggi, non si dovrebbe stare.