Che cos'è l'OWASP Top 10?
Un sviluppatore effettua il push del codice il venerdì pomeriggio. Entro lunedì, un attaccante ha manipolato un parametro API, ha avuto accesso ai dati dei clienti e li ha esfiltrati sfruttando una vulnerabilità di controllo degli accessi che un semplice controllo di autorizzazione avrebbe potuto bloccare. Questo è il tipo di vulnerabilità che l'OWASP Top 10 esiste per prevenire.
L'OWASP Foundation definisce l'OWASP Top 10 come "un documento standard di sensibilizzazione per sviluppatori e la sicurezza delle applicazioni web. Rappresenta un ampio consenso sui rischi di sicurezza più critici per le applicazioni web." L'elenco ha subito diverse edizioni e l'introduzione del 2025 ha introdotto cambiamenti strutturali che riflettono come il panorama della sicurezza applicativa sia cambiato.
NIST e il MITRE CWE Content Team fanno riferimento formale alle categorie dell'OWASP Top 10 nei propri framework. Se gestisci un programma di sicurezza, sviluppi applicazioni o gestisci la risposta alle vulnerabilità, l'OWASP Top 10 rappresenta la base che gli stakeholder si aspettano venga affrontata. Ecco cosa copre l'edizione attuale e come ogni categoria si applica al tuo ambiente.
Le categorie OWASP Top 10 del 2025
L'edizione 2025 ha riorganizzato le priorità sulla base di dati reali. Ecco tutte e dieci le categorie nell'attuale classifica, con i cambiamenti rilevanti per il tuo programma di sicurezza.
A01: Broken Access Control
Rimane la categoria principale, con il 3,73% delle applicazioni testate che presenta almeno una vulnerabilità correlata. Il controllo degli accessi non adeguato consente agli utenti di agire al di fuori dei permessi previsti, ad esempio modificando un parametro URL per visualizzare i dati di un altro utente, aumentando i privilegi tramite la manipolazione di token JWT o aggirando completamente le restrizioni a livello di funzione. Questo include IDOR, controlli di accesso mancanti e configurazioni errate di CORS. L'SSRF, precedentemente una categoria a sé stante, è ora consolidata qui.
A02: Security Misconfiguration
Salita dalla posizione #5 del 2021, riflettendo quanto il comportamento delle applicazioni moderne dipenda dalla configurazione più che dal codice. Questa categoria include credenziali di default non modificate, servizi non necessari esposti, messaggi di errore troppo dettagliati che rivelano stack trace e header di sicurezza mancanti. Gli ambienti cloud e i deployment containerizzati hanno amplificato il rischio perché ogni nuovo servizio, API gateway o cluster Kubernetes introduce una propria superficie di configurazione.
A03: Software Supply Chain Failures
Il cambiamento strutturale più rilevante dell'edizione 2025. In precedenza limitata a "Componenti vulnerabili e obsoleti", questa categoria ora copre l'intero ecosistema di dipendenze software, sistemi di build e infrastruttura di distribuzione. Gli attaccanti prendono sempre più di mira pipeline CI/CD, strumenti di sviluppo, registry di container e pacchetti open source ampiamente utilizzati, piuttosto che il codice applicativo direttamente. Nonostante le occorrenze siano meno frequenti nei dati, questa categoria presenta i punteggi medi di exploit e impatto più elevati nel dataset 2025.
A04: Cryptographic Failures
Rinominata da "Sensitive Data Exposure" per concentrarsi sulle cause radice piuttosto che sui sintomi. Questa categoria include dati trasmessi in chiaro, funzioni hash deprecate (MD5, SHA1), password utilizzate come chiavi crittografiche e casualità insufficiente. Quando le protezioni crittografiche falliscono, gli attaccanti possono intercettare credenziali in transito, decifrare dati archiviati o falsificare token di autenticazione. Il cambio di nome riflette l'orientamento OWASP verso l'individuazione delle cause dell'esposizione dei dati invece che la semplice catalogazione degli eventi di esposizione.
A05: Injection
L'injection si verifica quando un'applicazione passa input non attendibili a un interprete senza la dovuta validazione o escaping, consentendo agli attaccanti di eseguire comandi non previsti. SQL injection, cross-site scripting (XSS), injection di comandi OS e LDAP injection rientrano tutti in questa categoria. Sebbene l'injection sia scesa dalla posizione #3 alla #5 nella classifica 2025, resta una delle categorie con il maggior numero di CVE associati e rimane una delle principali cause di data breach quando la gestione degli input viene trascurata.
A06: Insecure Design
Questa categoria riguarda difetti a livello architetturale e di design, piuttosto che bug di implementazione. Un flusso di reset password debole, un passaggio di autorizzazione mancante in un workflow di business o l'assenza di rate limiting su un endpoint sensibile sono tutte decisioni di design, e nessuna quantità di codice sicuro può correggere un design fondamentalmente insicuro. OWASP ha introdotto questa categoria per enfatizzare il threat modeling, i pattern di design sicuro e le attività di sicurezza pre-codice. Il calo dalla posizione #4 alla #6 nel 2025 suggerisce che il settore sta gradualmente migliorando in quest'area.
A07: Identification and Authentication Failures
Questa categoria copre le debolezze che consentono agli attaccanti di compromettere le identità degli utenti: credential stuffing, attacchi brute-force contro password deboli, assenza di autenticazione multi-fattore (MFA) e difetti nella gestione delle sessioni come token di sessione prevedibili o invalidazione impropria. L'analisi OWASP rileva che l'uso crescente di framework di autenticazione standardizzati sta avendo un effetto positivo sui tassi di occorrenza, anche se le credenziali rubate restano uno dei vettori di accesso iniziale più comuni nei breach.
A08: Software or Data Integrity Failures
Questa categoria prende di mira le assunzioni di fiducia negli aggiornamenti software, pipeline CI/CD e serializzazione dei dati. Quando le applicazioni si aggiornano automaticamente senza verificare le firme, scaricano dipendenze da fonti non verificate o deserializzano dati non attendibili senza validazione, gli attaccanti possono iniettare codice malevolo che viene eseguito con i privilegi completi dell'applicazione. La categoria copre anche l'integrità delle pipeline CI/CD, dove una fase di build compromessa può distribuire artefatti malevoli in produzione senza essere rilevata.
A09: Security Logging and Alerting Failures
Il cambio di nome da "Security Logging and Monitoring Failures" è intenzionale: "Alerting" sostituisce "Monitoring" perché, secondo l' introduzione 2025 di OWASP, "un ottimo logging senza alerting ha un valore minimo" nell'identificazione degli incidenti di sicurezza. Senza alerting azionabile collegato alle fonti di log, le violazioni passano inosservate mentre le prove restano archiviate. Questa categoria include anche dettagli insufficienti nei log, audit trail mancanti per azioni sensibili e log che non registrano eventi di autenticazione o controllo degli accessi.
A10: Mishandling of Exceptional Conditions
Nuova nell'edizione 2025, questa categoria riguarda ciò che accade quando le applicazioni incontrano input inattesi, carenze di risorse, timeout o errori interni. Una gestione errata delle eccezioni può esporre dati sensibili tramite stack trace dettagliati, aggirare i controlli di sicurezza tramite logiche fail-open o creare condizioni di denial-of-service. OWASP ha consolidato 24 CWE precedentemente distribuiti tra problemi di "code quality" in questa categoria, riflettendo il crescente riconoscimento che i sistemi fragili che si interrompono in modo non sicuro rappresentano una classe di rischio distinta e sfruttabile.
La tabella seguente riassume ogni categoria e cosa è cambiato nell'edizione 2025.
| # | Categoria | Cosa è cambiato nel 2025 |
| A01 | Broken Access Control | Ora include SSRF, precedentemente una categoria separata |
| A02 | Security Misconfiguration | Salita dalla posizione #5 nel 2021 |
| A03 | Software Supply Chain Failures | Espansa da "Vulnerable and Outdated Components" per coprire l'intero ecosistema di dipendenze |
| A04 | Cryptographic Failures | Scende dalla posizione #2; il focus resta sulle problematiche di cifratura alla radice |
| A05 | Injection | Scende dalla posizione #3 alla #5; resta una delle categorie più testate |
| A06 | Insecure Design | Scende dalla posizione #4 alla #6; il settore sta migliorando nell'adozione del threat modeling |
| A07 | Authentication Failures | Posizione invariata; lieve aggiornamento del nome da "Identification and Authentication Failures" |
| A08 | Software or Data Integrity Failures | Posizione invariata |
| A09 | Security Logging and Alerting Failures | Rinominata; "Alerting" sostituisce "Monitoring" per riflettere l'esigenza operativa |
| A10 | Mishandling of Exceptional Conditions | Nuova categoria; sostituisce la precedente voce SSRF |
Queste categorie definiscono la baseline. Prima di vedere come correggere ciascuna, è utile capire perché questi rischi specifici hanno un peso organizzativo.
Perché l'OWASP Top 10 è importante
Il divario tra la scoperta di una vulnerabilità e la sua exploitazione continua a ridursi, e le applicazioni web restano un punto di ingresso primario. Per la tua organizzazione, l'OWASP Top 10 è importante per tre motivi.
- Prioritizzazione del rischio. Non puoi correggere tutto contemporaneamente. La Top 10 offre un punto di partenza basato sui dati, classificato per sfruttabilità e impatto, non solo per gravità teorica.
- Allineamento normativo. Il NIST CSF mantiene mappature incrociate con le varianti dell'OWASP Top 10. Quando auditor o regolatori chiedono del tuo programma di sicurezza applicativa, l'OWASP Top 10 è il linguaggio comune.
- Realismo finanziario. I fallimenti di sicurezza nel controllo degli accessi, nella configurazione e nell'injection possono diventare incidenti costosi. L'OWASP Top 10 aiuta i tuoi team a concentrarsi sulle classi di vulnerabilità più probabili a generare impatti operativi e di business.
Comprendere perché questi rischi sono importanti è il primo passo. Il successivo è sapere come affrontare ciascuno a livello di codice e configurazione.
Come prevenire le vulnerabilità OWASP Top 10
Ogni categoria dell'OWASP Top 10 ha passaggi di prevenzione specifici che i tuoi team possono implementare direttamente.
- A01: Broken access control. Applica la negazione per impostazione predefinita su tutti gli endpoint. Valida i permessi lato server su ogni richiesta e consolida in una singola routine di controllo degli accessi applicata in modo coerente su tutto il codice. Disabilita la visualizzazione delle directory e assicurati che le policy CORS limitino le origini ai soli domini attendibili.
- A02: Security misconfiguration. Rimuovi le credenziali di default, disabilita servizi e funzionalità non utilizzate e automatizza gli audit di configurazione su tutti gli ambienti. Mantieni aggiornati gli header di sicurezza e assicurati che i messaggi di errore restituiscano risposte generiche invece di stack trace.
- A03: Software supply chain failures. Fissa le dipendenze a versioni specifiche e verifica l'integrità con firme crittografiche o checksum. Mantieni una SBOM, esegui audit su plugin CI/CD e strumenti di sviluppo e monitora i database delle vulnerabilità per difetti noti nella tua catena di dipendenze.
- A04: Cryptographic failures. Utilizza standard di cifratura aggiornati (TLS 1.2+, AES-256) e dismetti algoritmi deprecati come MD5 e SHA1. Archivia le password con funzioni di hashing adattive come bcrypt o Argon2. Classifica i dati per sensibilità così da applicare il giusto livello di protezione agli asset appropriati.
- A05: Injection. Usa query parametrizzate per tutte le operazioni su database. Valida e sanifica tutti gli input utente ed esegui l'escaping dell'output per il contesto di rendering specifico (HTML, JavaScript, SQL). Applica policy di sicurezza dei contenuti per ridurre l'impatto XSS.
- A06: Insecure design. Conduci threat modeling prima di scrivere codice, esegui test di abuso insieme ai test funzionali e applica pattern di design sicuro dai Proactive Controls OWASP. I difetti di design sono più economici da correggere in fase di architettura che in produzione.
- A07: Authentication failures. Applica MFA, implementa il throttling dei login con limiti massimi di tentativi e utilizza framework di autenticazione standardizzati. Invalida correttamente le sessioni al logout e al cambio password.
- A08: Software or data integrity failures. Firma crittograficamente tutti gli artefatti di build, le immagini container e gli aggiornamenti software. Valida l'input in deserializzazione e limita l'accesso in scrittura alle pipeline CI/CD solo ai ruoli autorizzati.
- A09: Security logging and alerting failures. Configura soglie di alerting azionabili per i fallimenti di autenticazione, le violazioni del controllo degli accessi e i tentativi di escalation dei privilegi. Verifica che gli alert vengano generati in condizioni reali, non solo che i log vengano acquisiti.
- A10: Mishandling of exceptional conditions. Definisci modalità di errore sicure che chiudano e neghino l'accesso in caso di errore. Restituisci messaggi di errore generici agli utenti mentre registri dettagli diagnostici internamente. Gestisci esplicitamente valori null, esaurimento delle risorse e tipi di input inattesi.
La prevenzione per categoria affronta le correzioni tecniche. Scalare queste correzioni in tutta l'organizzazione è dove emergono le sfide di implementazione.
Sfide ed errori comuni nell'implementazione dell'OWASP Top 10
Operazionalizzare l'OWASP Top 10 in un ambiente di produzione con centinaia di applicazioni, decine di team di sviluppo e cicli di deployment continuo è dove l'implementazione si interrompe. Questi sono i pattern che causano i danni maggiori.
- Trattare la Top 10 come una checklist pass/fail. OWASP descrive esplicitamente la Top 10 come una guida di sensibilizzazione, non un programma di sicurezza. Per i test di verifica, OWASP raccomanda l'ASVS. Per la sola copertura della supply chain, la Top 10 è considerata solo "Occasionalmente" sufficiente.
- Implementazioni frammentate del controllo degli accessi. Il progetto Proactive Controls avverte contro la presenza di più implementazioni di controllo degli accessi sparse nel codice. Una sola implementazione difettosa resta sfruttabile anche se tutte le altre sono corrette.
- Configurazioni permissive per impostazione predefinita. Non applicare la negazione per default su REST API e webhook significa che ogni endpoint non gestito è implicitamente accessibile. Questo vale per servizi cloud, RBAC Kubernetes e API gateway.
- Autorizzazione su larga scala. L'autenticazione sta migliorando, ma il controllo degli accessi no. Il settore sta risolvendo il "chi sei?" ma fatica con "cosa dovresti poter fare?" su API e microservizi.
- Logging senza alerting. Puoi avere terabyte di log acquisiti nel tuo SIEM, ma se nessuno configura soglie di alerting azionabili, gli incidenti passano inosservati mentre le prove restano archiviate.
- Affidarsi esclusivamente a scansioni basate su enumerazione. Gli strumenti basati su enumerazione possono trovare solo ciò che già sai cercare. Difetti logici, nuove configurazioni errate e debolezze architetturali richiedono analisi comportamentale, non solo matching di signature.
Questi pattern persistono quando i programmi di sicurezza trattano l'OWASP Top 10 come un audit una tantum invece che una pratica operativa continua.
Best practice OWASP Top 10
Oltre alle correzioni per categoria, queste pratiche a livello di programma aiutano a operazionalizzare l'OWASP Top 10 in tutta l'organizzazione.
- Costruisci una libreria centralizzata di controlli di sicurezza. Secondo le linee guida di programma, definisci librerie condivise e riutilizzabili per autenticazione, autorizzazione, validazione degli input e crittografia. Quando ogni team crea la propria implementazione, le incoerenze creano lacune sfruttabili.
- Mappa i Proactive Controls sul tuo workflow di sviluppo. I Proactive Controls forniscono un complemento orientato agli sviluppatori rispetto alla Top 10 focalizzata sul rischio. C1 (Access Control) corrisponde ad A01, C3 (Input Validation) ad A05, C5 (Secure Defaults) ad A02. Fornisci ai tuoi sviluppatori controlli specifici da implementare, non solo rischi da evitare.
- Usa OWASP ASVS come baseline di verifica. Sostituisci i penetration test ad hoc con requisiti ASVS strutturati e mappati su ciascuna categoria della Top 10. ASVS fornisce criteri testabili in formato CSV e JSON per l'integrazione programmatica.
- Integra con NIST SSDF per l'allineamento normativo. NIST SP 800-218 fa esplicito riferimento a OWASP ASVS, OWASP SAMM e OWASP SCVS come framework complementari e si allinea ai requisiti dell'Executive Order 14028.
Queste pratiche creano la base programmatica. Il testing valida che i controlli di prevenzione funzionino come previsto.
Come testare rispetto all'OWASP Top 10
Nessun singolo strumento copre tutte e dieci le categorie. Un testing efficace dell'OWASP Top 10 combina analisi statica, test dinamici e analisi della composizione per coprire rischi a livello di codice, runtime e dipendenze.
- Static application security testing (SAST) analizza il codice sorgente alla ricerca di pattern di injection, debolezze crittografiche e difetti di autenticazione prima del deployment. Il SAST intercetta i problemi nelle prime fasi di sviluppo, quando le correzioni sono meno costose.
- Dynamic application security testing (DAST) testa le applicazioni in esecuzione per individuare lacune nel controllo degli accessi, configurazioni errate e errori nella gestione degli errori simulando traffico di attacco reale su endpoint attivi. OWASP ZAP è uno strumento DAST open source ampiamente utilizzato e mantenuto dalla community OWASP.
- Software composition analysis (SCA) identifica vulnerabilità note in librerie di terze parti, framework e immagini container confrontando la tua catena di dipendenze con i database pubblici delle vulnerabilità.
- Penetration testing valida il tuo ambiente specifico, individuando difetti logici e debolezze architetturali che gli strumenti automatici non rilevano. Mappa i risultati dei penetration test ai requisiti ASVS per una verifica strutturata.
La tabella seguente mappa ciascun metodo di test alle categorie OWASP Top 10 che copre più direttamente.
Metodo | Categorie coperte | Miglior utilizzo |
SAST | A04, A05, A07 | Durante lo sviluppo, prima del merge del codice |
| DAST | A01, A02, A10 | Su applicazioni in esecuzione in staging o produzione |
| SCA | A03, A08 | Durante la build e a ogni aggiornamento delle dipendenze |
| Penetration testing | Tutte le 10 categorie | Validazione periodica, dopo rilasci maggiori |
Combinando questi metodi ottieni copertura su tutte le dieci categorie dell'OWASP Top 10. Gli strumenti autonomi colmano il divario tra ciò che trovi e la velocità di risposta.
Key Takeaways
L'OWASP Top 10 è il framework di riferimento del settore per i rischi di sicurezza delle applicazioni web, aggiornato nel 2025 con una copertura ampliata della supply chain e un nuovo focus sull'alerting insieme al logging. Broken Access Control resta la categoria principale. Ogni categoria ha passaggi di prevenzione specifici e implementabili, dal controllo degli accessi deny-by-default alla verifica crittografica degli artefatti.
Un'implementazione efficace richiede controlli di sicurezza centralizzati, test stratificati tra SAST, DAST e SCA, e indagini autonome che colmino il divario tra la velocità di exploit e la velocità di risposta.
Domande frequenti
L'OWASP Top 10 è un documento di sensibilizzazione standard pubblicato dalla OWASP Foundation che identifica i rischi di sicurezza più critici per le applicazioni web.
Basato su dati reali di vulnerabilità e sondaggi della comunità, l'elenco fornisce una classifica guidata dal consenso che sviluppatori, team di sicurezza e auditor utilizzano come base per i programmi di sicurezza applicativa. L'edizione attuale è stata rilasciata nel 2025.
L'OWASP Top 10 non segue un calendario di rilascio fisso. Gli aggiornamenti vengono pubblicati quando nuovi dati sulle vulnerabilità e contributi della comunità giustificano una revisione della classifica.
Le edizioni precedenti sono state rilasciate nel 2013, 2017, 2021 e 2025. Ogni aggiornamento riflette cambiamenti nei modelli di sfruttamento reali, nelle architetture applicative e nelle metodologie di raccolta dati, piuttosto che solo proiezioni teoriche di rischio.
Il Top 10 è un documento di sensibilizzazione progettato per evidenziare le categorie di rischio più critiche per le applicazioni web. L'ASVS (Application Security Verification Standard) fornisce requisiti di verifica strutturati e testabili su tre livelli di garanzia, rendendolo adatto per test di sicurezza e revisione del codice.
OWASP stessa raccomanda ASVS per le revisioni di progettazione e le valutazioni di sicurezza, posizionando il Top 10 come punto di ingresso e ASVS come framework di verifica.
Le Top 10 delle applicazioni web coprono categorie rilevanti per le API, in particolare Broken Access Control (A01) e Injection (A05). Tuttavia, OWASP mantiene una Top 10 API Security separata con categorie specifiche per l'autorizzazione delle API, il rate limiting e il controllo degli accessi a livello di oggetto.
Diversi rischi principali per le API sono direttamente collegati a errori di autorizzazione che rispecchiano A01. Le organizzazioni con un'esposizione significativa alle API dovrebbero affrontare entrambe le liste per garantire una copertura adeguata.
La metodologia 2025 ha ampliato il dataset analizzato e introdotto un ciclo di contributo dati più esteso insieme alla componente del sondaggio comunitario OWASP per i rischi prospettici.
La formula di ponderazione ha continuato a bilanciare sfruttabilità e impatto tecnico, riflettendo al contempo un corpus di vulnerabilità più ampio. Questa espansione metodologica, e non solo il cambiamento dei modelli di minaccia, ha determinato diverse variazioni nelle classifiche, tra cui l'ascesa della Configurazione di Sicurezza Errata e l'aggiunta della Gestione Inadeguata delle Condizioni Eccezionali come nuova categoria.
No. OWASP dichiara esplicitamente che il Top 10 è uno strumento di sensibilizzazione e formazione di base. Per la sola sicurezza della supply chain, il Top 10 è considerato solo "Occasionalmente" sufficiente.
Un programma completo dovrebbe includere OWASP ASVS per la verifica, OWASP SAMM per la valutazione della maturità, NIST SSDF per l'integrazione nel SDLC e una protezione continua in fase di esecuzione per coprire i rischi che il Top 10 non è stato progettato per affrontare.
