OWASP Top 10 2025: cosa deve verificare un IT Manager
OWASP Top 10 2025: cosa deve verificare un IT Manager
In questo articolo
La OWASP Top 10 2025 identifica le principali categorie di rischio per applicazioni web e API. Per IT Manager e CISO rappresenta un punto di partenza per stabilire quali applicazioni controllare, quali verifiche richiedere e come coinvolgere sviluppatori e fornitori.
Le priorità del 2025 riguardano soprattutto controllo degli accessi, configurazioni di sicurezza e software supply chain.
CURIOSITÀ
Perché nel logo OWASP compare una vespa?
La spiegazione è contenuta nell’acronimo: le lettere W-A-S-P formano la parola inglese wasp, che significa “vespa”. L’insetto è così diventato l’elemento distintivo dell’identità visiva di OWASP, tanto che le linee guida ufficiali del brand lo definiscono il suo “emblema caratterizzante”.
OWASP Top Ten: come nasce e cosa è cambiato rispetto al 2021
OWASP (Open Web Application Security Project) è un’organizzazione no profit che ha come scopo quello di fornire soluzioni top di gamma per quanto riguarda l’application security. L’organizzazione pubblica periodicamente la OWASP Top Ten, nota anche come Web Application security risks, oltre a fornire consigli e tool gratuiti per aiutare sviluppatori e Team IT nello sviluppo di strategie di cyber security.
L’edizione 2025 aggiorna le priorità rispetto alla precedente versione del 2021. Il controllo degli accessi resta al primo posto, mentre acquistano maggiore rilevanza gli errori di configurazione e i rischi legati alla software supply chain. Entra inoltre una nuova categoria dedicata alla gestione delle condizioni eccezionali, come errori applicativi, timeout e comportamenti imprevisti.
Per un IT Manager, il valore della OWASP Top 10 va oltre la conoscenza delle singole vulnerabilità. Il documento può essere utilizzato per definire il perimetro delle applicazioni da analizzare, assegnare le priorità, scegliere le attività di verifica e richiedere evidenze concrete a software house e fornitori SaaS.
In questa guida vedremo quindi che cosa cambia nella OWASP Top 10 2025 e come tradurre le sue indicazioni in controlli applicabili ad applicazioni, API, infrastrutture cloud e processi di sviluppo.
OWASP Top Ten: come sfruttarla nella gestione della sicurezza aziendale
La OWASP Top 10 è un documento di riferimento dedicato alla sicurezza delle applicazioni web. Raccoglie dieci ampie categorie di rischio, ognuna delle quali comprende diverse vulnerabilità e debolezze applicative. Si tratta una mappa delle aree sulle quali sviluppatori, responsabili IT e security team dovrebbero concentrare l’attenzione.
La selezione viene elaborata combinando i dati raccolti attraverso test di sicurezza condotti su applicazioni reali con le valutazioni della comunità internazionale di application security. L’obiettivo è offrire un linguaggio condiviso con cui riconoscere i rischi, confrontare le priorità e orientare le attività di prevenzione e verifica.
Vuoi restare aggiornato sulle ultime novità dal mondo della Cyber Security?
ISCRIVITI ALLA NEWSLETTER
La OWASP Top 10 funziona come documento di sensibilizzazione e punto di partenza per un programma di application security. Per trasformarla in uno strumento operativo, l’IT Manager deve collegare le categorie OWASP al proprio parco applicativo, alla criticità dei processi aziendali e ai dati trattati.
Può essere utilizzata per:
- censire applicazioni web, portali, API e servizi esposti
- classificare gli applicativi in base a criticità, dati trattati ed esposizione
- definire i controlli minimi richiesti per ogni livello di rischio
- pianificare vulnerability assessment, penetration test e verifiche sul codice
- stabilire requisiti di sicurezza per software house e fornitori SaaS
- assegnare responsabilità e tempi di remediation
- monitorare KPI come copertura dei test, vulnerabilità aperte e rispetto degli SLA
La Top 10 offre quindi una direzione, mentre strumenti come l’OWASP Application Security Verification Standard, o ASVS, permettono di definire requisiti tecnici verificabili. Il modello OWASP SAMM può invece supportare la valutazione della maturità dei processi di sviluppo sicuro.
L’approccio consigliato è quello di evitare di utilizzare la OWASP Top 10 come una semplice checklist per inserirla in un programma continuativo di gestione del rischio applicativo.
Che cosa cambia dalla OWASP Top 10 2021 alla versione 2025
La OWASP Top 10 2025 introduce due nuove categorie e consolida nella voce Broken Access Control la Server-Side Request Forgery, che nel 2021 occupava una posizione autonoma. Accanto agli spostamenti in classifica emerge soprattutto un ampliamento del perimetro: la sicurezza applicativa coinvolge sempre più configurazioni, dipendenze, pipeline di sviluppo, servizi esterni e capacità di gestire condizioni impreviste.
Il cambiamento più evidente riguarda la parte alta della classifica. Broken Access Control resta al primo posto, Security Misconfiguration sale dalla quinta alla seconda posizione e Software Supply Chain Failures entra al terzo posto, ampliando il precedente riferimento ai componenti vulnerabili e obsoleti.
L’elenco attuale dei 10 rischi OWASP
| Posizione | Categoria OWASP 2025 | Cambiamento rispetto al 2021 |
|---|---|---|
| A01 | Broken Access Control | Resta al primo posto e comprende anche la SSRF |
| A02 | Security Misconfiguration | Sale dalla quinta alla seconda posizione |
| A03 | Software Supply Chain Failures | Amplia la categoria dedicata ai componenti vulnerabili e obsoleti |
| A04 | Cryptographic Failures | Passa dalla seconda alla quarta posizione |
| A05 | Injection | Passa dalla terza alla quinta posizione |
| A06 | Insecure Design | Passa dalla quarta alla sesta posizione |
| A07 | Authentication Failures | Resta al settimo posto con una denominazione più diretta |
| A08 | Software or Data Integrity Failures | Resta all’ottavo posto con una modifica nella denominazione |
| A09 | Security Logging and Alerting Failures | Resta al nono posto e rafforza il ruolo dell’alerting |
| A010 | Mishandling of Exceptional Conditions | Nuova categoria dedicata alla gestione delle condizioni anomale |
Perché questi cambiamenti dovrebbero interessare l’IT Manager
L’aggiornamento del 2025 sposta ulteriormente l’attenzione dal singolo errore di programmazione al modo in cui applicazioni e servizi vengono progettati, configurati, distribuiti e gestiti nel tempo.
La crescita di Security Misconfiguration evidenzia l’importanza di controllare configurazioni cloud, account predefiniti, permessi, servizi esposti e impostazioni applicative lungo l’intero ciclo di vita. Il nuovo perimetro della software supply chain richiede invece visibilità su librerie, dipendenze, repository, pipeline CI/CD, strumenti di sviluppo e processi di aggiornamento.
Anche il cambiamento della categoria A09 è significativo. Raccogliere i log rappresenta solo una parte del processo perchè gli eventi rilevanti devono generare alert, responsabilità e procedure di risposta. La nuova categoria A10 aggiunge infine un tema spesso trascurato, cioè la capacità dell’applicazione di gestire errori, timeout, risorse esaurite e input imprevisti mantenendo un comportamento sicuro.
Per l’IT Manager, la nuova classifica richiede quindi una verifica che coinvolga applicazioni, API, infrastrutture, strumenti di sviluppo e fornitori. Il primo passo consiste nel capire quali sistemi rientrano nel perimetro e quali devono essere controllati per primi.
Quali applicazioni e servizi devono essere valutati
L’applicazione della OWASP Top 10 parte dalla conoscenza del parco applicativo aziendale. Per stabilire quali verifiche effettuare e con quale priorità, l’IT Manager deve disporre di un inventario aggiornato di applicazioni, API, servizi cloud, integrazioni e componenti utilizzati dall’organizzazione.
Il perimetro comprende i servizi esposti su Internet, come portali clienti e-commerce e aree riservate, ma anche gli applicativi interni che gestiscono dati sensibili, processi produttivi, attività amministrative o funzioni essenziali per la continuità operativa. Particolare attenzione va riservata alle API, spesso utilizzate per collegare applicazioni, servizi cloud e piattaforme di terze parti.
| Elemento da censire | Che cosa verificare |
|---|---|
| Siti e portali web | Autenticazione, ruoli, sessioni, form, aree riservate e configurazioni |
| API e servizi di integrazione | Autorizzazioni, token, endpoint esposti, rate limiting e scambio dei dati |
| Applicazioni sviluppate internamente | Codice, dipendenze, configurazioni, pipeline e processi di rilascio |
| Software sviluppato da fornitori | Requisiti contrattuali, test effettuati, vulnerabilità aperte e tempi di remediation |
| Piattaforme SaaS | SSO, MFA, ruoli, log disponibili, gestione degli aggiornamenti e protezione dei dati |
| Applicazioni legacy | Tecnologie obsolete, componenti fuori supporto, account privilegiati e integrazioni |
| Repository e pipeline CI/CD | Credenziali, dipendenze, permessi, firme degli artefatti e protezione dei processi di build |
| Console e pannelli amministrativi | Esposizione, privilegi, autenticazione forte e registrazione delle attività |
L’impatto dei fornitori
Quando un’applicazione viene gestita da una software house o acquistata come servizio SaaS, la responsabilità operativa è condivisa con il fornitore, mentre la governance del rischio resta in capo all’organizzazione che utilizza il servizio.
In questi casi, l’IT Manager può richiedere evidenze come report di penetration test, processi di vulnerability management, tempi previsti per la correzione delle vulnerabilità, modalità di gestione degli accessi privilegiati, disponibilità dei log e procedure applicate alla software supply chain. Le attività di test diretto sui servizi del fornitore devono essere previste dagli accordi e autorizzate.
Come stabilire quali applicazioni controllare per prime
Tutte le applicazioni meritano un livello minimo di protezione, ma profondità e frequenza delle verifiche devono essere proporzionate al rischio. Una classificazione iniziale può essere costruita valutando esposizione, dati trattati, impatto sul business e dipendenze tecnologiche.
| Criterio | Domanda da porsi | Priorità più elevata quando |
|---|---|---|
| Esposizione | L’applicazione è raggiungibile da Internet? | Il servizio è pubblico o accessibile da utenti esterni |
| Dati trattati | Quali informazioni gestisce? | Sono presenti dati personali, finanziari, sanitari o riservati |
| Continuità operativa | Che cosa succede se il servizio si blocca? | Il fermo interrompe attività essenziali |
| Privilegi | Quali operazioni possono eseguire gli utenti? | Sono presenti account amministrativi o funzioni critiche |
| Integrazioni | Con quali sistemi comunica? | L’applicazione accede a più ambienti o scambia dati sensibili |
| Frequenza delle modifiche | Quanto spesso viene aggiornata? | Sono previsti rilasci frequenti o molte dipendenze esterne |
| Obsolescenza | Tecnologie e componenti sono supportati? | Sono presenti versioni legacy o componenti fuori supporto |
| Visibilità | Disponiamo di log, documentazione e report? | Le evidenze disponibili sono incomplete o poco aggiornate |
La classificazione delle priorità
Sulla base di questi criteri, il parco applicativo può essere suddiviso in tre livelli:
Il risultato dovrebbe confluire nell’inventario applicativo o nella CMDB, associando a ogni sistema un responsabile, il livello di criticità, i controlli eseguiti, le vulnerabilità aperte e la data della prossima verifica.
La metodologia riprende l’approccio risk-based indicato da OWASP per la costruzione di un programma moderno di application security: identificare le esigenze di protezione, classificare applicazioni e API e rendere visibili le priorità al management.
Perché il Broken Access Control resta al primo posto nella OWASP Top 10 2025
Il Broken Access Control si verifica quando un’applicazione permette a un utente o a un servizio di visualizzare dati, utilizzare funzioni o compiere operazioni che escono dal perimetro delle autorizzazioni assegnate.
Il problema riguarda quindi l’autorizzazione, cioè la verifica di ciò che un’identità può effettivamente fare dopo avere completato l’autenticazione. Un accesso con credenziali valide può comunque diventare un rischio quando l’applicazione non controlla correttamente ruoli, privilegi, proprietà dei dati e operazioni consentite. Questa categoria mantiene il primo posto nella OWASP Top 10 2025 e incorpora anche la Server-Side Request Forgery, che nell’edizione 2021 costituiva una voce autonoma. Nei dati raccolti da OWASP è la categoria con il maggior numero di occorrenze.
Come si manifesta un problema di controllo degli accessi
Un errore di autorizzazione può consentire a un utente di accedere ai dati di un altro account, utilizzare funzioni amministrative, modificare informazioni riservate o richiamare operazioni API previste per un profilo con privilegi superiori.
Alcuni casi ricorrenti comprendono:
- accesso a record appartenenti ad altri utenti attraverso la modifica di un identificativo
- funzioni amministrative raggiungibili da profili standard
- endpoint API privi di controlli coerenti per operazioni GET, POST, PUT e DELETE
- permessi verificati solamente nell’interfaccia front-end
- token, cookie o parametri utilizzabili per ottenere privilegi superiori
- configurazioni CORS che accettano richieste da origini non autorizzate
- file, directory o copie di backup accessibili dall’esterno
- sessioni e token che restano validi oltre il tempo necessario
Le verifiche da pianificare
L’IT Manager non deve necessariamente eseguire personalmente i test tecnici, ma deve assicurarsi che i controlli di autorizzazione siano documentati, verificati e applicati in modo coerente nelle applicazioni e nelle API.
Un controllo semplice ma rivelatore
Per ogni applicazione critica dovrebbe essere previsto almeno un test con profili dotati di privilegi differenti. Un utente standard deve poter utilizzare esclusivamente le funzioni e i dati assegnati, mentre ogni tentativo di accedere a risorse amministrative o appartenenti ad altri utenti deve essere bloccato e registrato.
La stessa verifica deve interessare le API: nascondere un pulsante o una funzione nell’interfaccia grafica non impedisce infatti di richiamare direttamente l’endpoint sottostante. I controlli devono essere applicati lato server, dove l’utente non può modificarli.
Che cosa chiedere a una software house o a un fornitore SaaS
Quando applicazione e infrastruttura sono gestite da un fornitore, l’IT Manager può chiedere come vengono definiti e testati i ruoli, se sono previsti test specifici sulle autorizzazioni, come viene protetta la separazione tra clienti e quali procedure governano token, accessi privilegiati e tentativi di violazione.
Le risposte dovrebbero essere supportate da documentazione tecnica, report di test, certificazioni pertinenti e impegni chiari sui tempi di correzione. Una dichiarazione generica di conformità alla OWASP Top 10 offre meno valore rispetto a evidenze verificabili sui controlli effettivamente implementate.
| Area di controllo | Domanda da porre | Evidenza da richiedere |
|---|---|---|
| Ruoli e privilegi | È definito che cosa può visualizzare e modificare ogni profilo? | Matrice dei ruoli e dei permessi |
| Privilegio minimo | Gli utenti ricevono solamente le autorizzazioni necessarie? | Policy di accesso e configurazioni applicative |
| Controlli server-side | Le autorizzazioni vengono verificate dal server per ogni richiesta? | Architettura applicativa e risultati dei test |
| Proprietà dei dati | Un utente può accedere esclusivamente ai record di propria competenza? | Test negativi su account, record e tenant |
| API | Tutti gli endpoint e i metodi applicano controlli coerenti? | Documentazione API e report di security testing |
| Sessioni e token | Scadenza, revoca e logout sono gestiti correttamente? | Configurazioni dell’Identity Provider e policy sui token |
| Origini e risorse | CORS, directory e file pubblici sono configurati in modo sicuro? | Checklist di hardening e configurazioni |
| Logging | I tentativi di accesso non autorizzato vengono registrati e segnalati? | Log di esempio, regole di alerting e procedure di risposta |
| Testing | I controlli di autorizzazione vengono verificati dopo modifiche rilevanti? | Test di integrazione, vulnerability assessment e penetration test |
Come sviluppare la tua strategia di cybersecurity in azienda secondo OWASP?
BeeCyber offre servizi di cyber security completi e personalizzati per proteggere le aziende da minacce informatiche, anche tramite strumenti AI. BeeCyber fornisce una valutazione approfondita dei rischi, gestione delle identità, sistemi di protezione dei dati, monitoraggio continuo delle minacce e risposte rapide agli incident.
I servizi includono penetration test, vulnerability assessment e consulenza strategica per garantire conformità alle normative come NIS2, GDPR, ISO 27001 e altri requisiti specifici del settore.
Le soluzioni su misura di BeeCyber, insieme alla formazione del personale, aiutano a mantenere i sistemi aziendali sicuri e operativi.
