Le OWASP Top 10 non sono dieci liste 📉
TL;DR: la domanda non è quale Top 10 sia quella vera. La domanda è quale parte del tuo sistema stai guardando, e quale stai convenientemente dimenticando.
Una lista per ogni confine 🗺️
La Top 10 Web è famosa perché il Web è stato a lungo il centro del software applicativo. Poi le API hanno iniziato a esporre oggetti e funzioni proprie, Kubernetes ha reso il control plane una superficie quotidiana, e gli LLM hanno aggiunto istruzioni ostili e tool eseguibili alla festa. Ogni tecnologia ha costruito il suo vocabolario di fallimenti, e ogni gruppo di lavoro OWASP ha raccolto quello. Il risultato è una famiglia di liste, non un’eccezione alla regola.
Non è frammentazione per sport. È specializzazione. Una BOLA non è una route amministrativa aperta; un RBAC permissivo non è un JWT mal validato; una prompt injection non è SQL injection con un cappello diverso. Chi le appiattisce in un’unica checklist non sta semplificando: sta nascondendo i meccanismi, e i meccanismi sono l’unica cosa che i controlli devono conoscere.
Quando la lista mente 🤥
Le liste “mentono” — nel senso nobile del termine — in almeno tre momenti. Mentono quando le usi come certificato di conformità: un’app che spunta tutte le voci Web può avere un’API aperta come un portone aziendale, perché la lista Web non parla di oggetti esposti. Mentono quando le prendi come graduatoria di rischio per il tuo contesto: la Top 10 misura prevalenza su un paniere globale, non il rischio del tuo dominio specifico; un’app con un solo esposto può avere un rischio gigante in una categoria in fondo alla lista. E mentono quando le leggi come categorie esclusive: il fatto che la prompt injection compaia nella lista LLM non la rende assente dal tuo codice Web che invoca un modello.
Il caso più divertente è il quinto: nel momento in cui una voce diventa famosa, gli attaccanti ci hanno già lavorato sopra per tre anni, e la lista — per definizione — fotografa il passato. Non è un difetto delle liste: è la natura del poliziotto che arriva dopo la rissa. Il problema è quando qualcuno crede che arrivare dopo significhi essere in tempo.
C’è anche un quarto tradimento, il più sottile: le liste vengono spesso usate come confini di reparto. “Io mi occupo di sicurezza Web, tu di LLM, lui di Kubernetes”: la tassonomia diventa uno steccato organizzativo che giustifica ownership separate su quello che è lo stesso concetto. Il risultato è una catena con anelli che non si parlano: la policy di access control scritta per il Web non migra sull’API, l’RBAC del cluster ignora l’excessive agency dell’agente, e nessuno si accorge che il punto di rottura è proprio il punto di connessione tra i reparti. Le liste sono ottime come lenti, pessime come muri: chi le usa per dividere domini, finisce per non vedere il rischio che li attraversa.
Le liste diventano inutili quando le usi per non pensare. Diventano potenti quando le usi per fare domande migliori.
Liste parallele, non in competizione 🔀
C’è chi legge la proliferazione delle liste come una guerra di successione e si perde chiedendosi quale sarà il Top 10 definitivo. Non lo sarà mai. Le liste parallele non si fanno concorrenza: si completano, perché nessuna copre da sola l’intera superficie. Lo stesso concetto cambia casa e si traveste: l’access control è BOLA nelle API, RBAC permissivo in Kubernetes, excessive agency nello spazio LLM. Il principio è lo stesso, la verifica non lo è, e una singola lista non ti basta mai.
Chi insiste sulla lista unica cerca la risposta prima di aver compreso il problema. Chi accetta la famiglia di liste smette di chiedersi quale sia quella vera e inizia a chiedersi come attraversarla: quale proprietà sto proteggendo, in quale dominio, con quale meccanismo. È il passaggio dalla ricerca di un certificato alla costruzione di una mappa — e una mappa, si sa, non è uno specchio: serve per orientarsi, non per compiacersi.
Da checklist a mappa 🧭
Il trucco è cercare la proprietà prima della categoria: autorizzazione, identità, provenienza, configurazione, telemetria. Poi osservare come fallisce nel dominio. Così scopri che access control ricompare in API, cluster e agenti, ma richiede test diversi e controlli diversi. La categoria è la superficie; la proprietà è il concetto; il meccanismo è il dominio.
È la distanza tra chi chiede “quale lista devo seguire?” e chi chiede “quali decisioni di fiducia sta prendendo questo componente?”. La prima domanda produce un documento da appendere al muro; la seconda produce un threat model, e i threat model — si dice — fanno la fortuna di chi li aggiorna e la sfortuna di chi li stampa e li incornicia.
La sicurezza che si legge bene è la sicurezza che non ha avuto bisogno di una riunione per essere capita.
La guida Ecosistema OWASP spiega le lenti principali; la tassonomia unificata le collega senza fingere che siano identiche. Il vero test per chi progetta: prendi il tuo sistema, scegli le colline giuste da guardare, e tratta ogni lista come una mappa in cui il territorio cambia più in fretta dei cartografi.