Vulnerabilità, rischio, impatto 📐
Confrontare una Top 10 con un’altra è utile soltanto se non si scambia una causa per un risultato. Le liste OWASP mescolano volutamente livelli diversi: è ciò che le rende operative, ma anche ciò che rende facile produrre equivalenze false.
La scala dei livelli 📊
| Livello | Domanda | Esempio |
|---|---|---|
| Debolezza | Che difetto strutturale esiste? | Autorizzazione assente lato server |
| Vulnerabilità | Dove è sfruttabile? | Endpoint che restituisce l’ordine di un altro utente |
| Minaccia | Chi e come può abusarne? | Attaccante modifica un ID |
| Controllo | Cosa previene o rileva? | Check ownership, log, test di autorizzazione |
| Impatto | Cosa accade se fallisce? | Esfiltrazione, frode, indisponibilità |
La scala non è ornamento: è lo strumento che ti impedisce di chiamare “data breach” una debolezza o “prompt injection” una vulnerabilità che si patcha. Ogni riga risponde a una domanda diversa e richiede controlli diversi. Una debolezza si elimina modificando il design; un impatto si mitiga con il rilevamento e la risposta.
Perché le liste mescolano i livelli 🌀
La confusione non è un difetto delle liste: è un effetto del loro metodo. La Web Top 10 del 2025 seleziona otto categorie da dati empirici (circa 2,8 milioni di applicazioni testate) e due da un sondaggio tra esperti — logging/alerting e supply chain — perché i test automatici le rilevano male. Vuol dire che, anche dentro la stessa lista, alcune righe misurano prevalenza reale e altre sono giudizio esperto su un rischio emergente. Non hanno lo stesso peso: è normale. Comportarsi come se l’avessero è il problema.
Oltretutto alcune categorie descrivono impatti o classi di attacco, non cause. Se una lista sul ciclo di vita dei dati elenca “Data Breaches” e “Malware/Ransomware” accanto a “Weak Cryptography”, stai guardando livelli diversi in una sola pagina: la prima riga è l’esito di un attacco, la terza è una possibile causa. Manageriale? Comodo. Rigoroso? No.
Gli outlier insegnano qualcosa 🧠
Web A02 parla di una classe di configurazioni insicure; API6 di un fallimento nel design del flusso di business; K01 e K09 sono configurazioni; alcune liste sui dati descrivono soprattutto outcome. Prompt injection è una tecnica di attacco da gestire, non una debolezza che si “patcha” separando perfettamente dati e istruzioni.
Il 2025 ha introdotto due livelli misti in più tra gli A-item. A10 (Mishandling of Exceptional Conditions) è una categoria di comportamento in condizioni anomale: errori che corrompono stato, rivelano dettagli o aggirano controlli. Non è una classica debolezza di codice — è più vicina a un fallimento operativo. A03 (Software Supply Chain Failures) è una categoria di ecosistema: difficile da far comparire nei test automatici proprio perché attraversa repository, build runner e artefatti esterni, e per questo OWASP l’ha promossa con il sondaggio invece che con i dati. Sono righe da leggere con la scala pronta.
Usare la scala, non idolatrarla ⚖️
Quando un item appartiene a un livello diverso da quello che ti aspettavi, annotalo e scegli controlli appropriati invece di forzarlo in una casella. La domanda giusta non è mai “è la stessa cosa?”, ma “a quale livello si manifesta qui?”.
Prendi l’access control: la debolezza (“manca un check server-side”), la vulnerabilità (“l’endpoint GET /api/v1/orders/{id} è sfruttabile come BOLA”), la minaccia (“attaccante enumera gli ID”), il controllo (“ownership check, rate limit, test di autorizzazione”) e l’impatto (“esfiltrazione degli ordini dei clienti”) occupano cinque righe diverse della scala ma finiscono tutte sotto A01 nella lista Web. Nessuna delle risposte è sbagliata: sono risposte a domande diverse.
Lo stesso vale per la supply chain: la rigorosa separazione tra “componente vulnerabile” (una libreria con un CVE, debolezza) e “componente compromesso alla fonte” (una pipeline avvelenata, minaccia e impatto insieme) è la differenza tra un fix e un incidente. La tassonomia 2025 la formalizza distinguendo A03 (ecosistema esterno) da A08 (integrità del tuo artefatto), che operano su piani diversi.
Le differenze di astrazione esistono anche tra progetti. La Desktop App Security 2021 ricalca la struttura pre-2021 della Web Top 10 (voci separate per “Sensitive Data Exposure”, “Broken Authentication” e “Using Components with Known Vulnerabilities”), mentre la Web 2025 ha consolidato le cause radice e assorbito SSRF in A01. Due progetti contemporanei che descrivono lo stesso problema a livelli diversi: la scala risolve la frase “non si capisce perché si chiamino diversamente”.
Un esempio completo: la prompt injection 🔬
Ripassiamo la scala con la prompt injection, l’outlier che tutti tengono in tasca. La debolezza è strutturale: il modello non separa istruzioni e dati nello stesso canale. La vulnerabilità si manifesta quando contenuto ostile arriva da una pagina indicizzata nel RAG e viene letto come contesto. La minaccia è un attaccante che controlla una pagina sperando che l’agente la consumi. I controlli sono capability ristrette, conferme umane, isolamento dei dati e eval adverary — non un filtro a monte. L’impatto può essere un rimborso non autorizzato o un’esfiltrazione di dati.
Annotare la riga giusta, qui, non è pedanteria: è ciò che impedisce di vendere “un filtro anti-prompt-injection” come soluzione. Il filtro tocca solo la minaccia; la debolezza resta, e aspetta la pagina sbagliata.
Regola pratica ✅
Per ogni categoria chiedi: quale proprietà protegge, qual è il meccanismo di fallimento, quali controlli lo riducono e quale impatto resta possibile? Se lo fai prima di confrontare due liste, scopri presto dove sono le vere equivalenze e dove ci sono solo somiglianze di nome.
- Identifico il livello di ogni categoria che confronto.
- Distinguo la causa dall’impatto nel caso concreto.
- Scelgo i controlli per il livello, non per il nome della categoria.
- Annoto gli outlier invece di forzarli in una casella.
- Verifico quale edizione e quale metodo hanno prodotto la riga.
Questa lente prepara la tassonomia unificata, che è una proposta analitica della serie, non una classificazione ufficiale OWASP. Se non l’hai ancora fatto, parti dall’ecosistema per scegliere le liste giuste per il tuo dominio.