A gennaio 2026 è arrivata la OWASP Top 10:2025, la prima revisione dopo quattro anni dello standard di riferimento sui rischi delle applicazioni web. Si è parlato molto di cosa è cambiato — due categorie nuove, qualche riordino, lo spostamento dal sintomo alla causa. Ma per un’azienda che porta i propri servizi online la domanda che conta è un’altra, e quasi nessuno la affronta: la mia applicazione web è davvero esposta a questi rischi? E soprattutto, come faccio a saperlo?

  1. Cosa è cambiato, in breve
  2. Perché conoscere la lista non vi mette al sicuro
  3. Cosa una scansione automatica trova davvero
  4. Le categorie che solo un test manuale rivela
  5. OWASP, NIS2 e le richieste dei clienti
Verifica di sicurezza di un'applicazione web rispetto alle categorie della OWASP Top 10 2025

Cosa è cambiato, in breve

La Top 10:2025 introduce due categorie nuove — Software Supply Chain Failures e Mishandling of Exceptional Conditions — riassorbe il Server-Side Request Forgery dentro Broken Access Control e riordina le posizioni. Il segnale di fondo è uno: il rischio si è spostato dal singolo errore di codice ai problemi sistemici, cioè a come l’applicazione viene costruita, configurata e mantenuta nel tempo, con le dipendenze di terze parti e gli errori di configurazione ormai in cima alla classifica.

Non ci dilunghiamo qui sulla descrizione di ciascuna categoria, perché il punto di questa guida non è cosa contiene la lista, ma cosa farci. Chi vuole il dettaglio delle dieci voci trova ovunque ottime spiegazioni; quello che manca, di solito, è il passaggio successivo.

Perché conoscere la lista non vi mette al sicuro

La Top 10 è un documento di consapevolezza, non una checklist che si spunta e nemmeno una garanzia. Sapere che esiste il Broken Access Control non vi dice se la vostra applicazione ha un controllo di accesso aggirabile. Conoscere la categoria Injection non vi dice se i vostri form filtrano davvero l’input come dovrebbero.

C’è una distanza enorme tra leggere la lista e sapere come si colloca la propria applicazione rispetto ad essa. Quella distanza si colma in un solo modo: verificando l’applicazione nello specifico. E qui nasce l’equivoco più costoso, perché esistono due modi molto diversi di verificare, che danno risultati molto diversi.

Cosa una scansione automatica trova davvero

Uno scanner di vulnerabilità confronta la vostra applicazione con un database di problemi noti: componenti datati, configurazioni errate riconoscibili, falle già catalogate. È utile, veloce e ripetibile, ed è il punto di partenza giusto. Su alcune categorie della Top 10 funziona bene: intercetta buona parte dei problemi di configurazione, segnala le dipendenze obsolete che ricadono nella supply chain, rileva diverse falle crittografiche evidenti.

Ma uno scanner trova ciò che è già noto e riconoscibile da una firma. Non capisce la logica della vostra applicazione, e proprio le categorie più gravi della Top 10:2025 vivono nella logica, non nelle firme. È il motivo per cui affidarsi solo alla scansione automatica lascia scoperte le voci più pericolose.

Le categorie che solo un test manuale rivela

Prendete il Broken Access Control, stabilmente la prima voce della classifica e quella che i tester trovano più spesso. Verificare se un utente può accedere ai dati di un altro account, o raggiungere una funzione amministrativa che non gli compete, richiede di provare attivamente a violare i controlli, ragionando come un attaccante. Nessuno scanner lo fa: bisogna conoscere i ruoli, costruire le richieste, tentare l’aggiramento. Lo stesso vale per gli errori di logica di business, per le concatenazioni di debolezze minori che insieme aprono una breccia seria, per il modo in cui l’applicazione gestisce condizioni anomale ed errori.

È esattamente il terreno del Web Application Penetration Testing: un’analisi con una forte componente manuale, in cui un analista mette alla prova l’applicazione sulle categorie OWASP che una scansione non può cogliere. La strategia più solida usa i due strumenti insieme — il Web Vulnerability Assessment per la copertura ampia e continua, il WAPT per la profondità dove conta. Se non avete chiaro quale dei due vi serve, abbiamo dedicato una guida a come scegliere tra Web Vulnerability Assessment e WAPT.

OWASP, NIS2 e le richieste dei clienti

La Top 10 non è una norma di legge, ma è diventata il riferimento implicito di gare d’appalto, capitolati e audit. Quando la direttiva NIS2 chiede di adottare misure adeguate e di verificarle in modo documentato, o quando un cliente enterprise vi domanda garanzie sulla sicurezza delle vostre applicazioni prima di firmare, il metro di giudizio è quasi sempre OWASP. “Le nostre applicazioni sono verificate rispetto alla OWASP Top 10” è una frase che apre porte; non poterla dire, sempre più spesso, le chiude.

In tutti questi casi conta poter mostrare un report che attesti la verifica. E un report serio, su queste categorie, nasce da un’analisi che va oltre la scansione automatica.

La OWASP Top 10:2025 vi dice quali sono i rischi; sapere se la vostra applicazione ne è esposta richiede una verifica concreta. Cyberment affianca le aziende italiane con il Web Application Penetration Testing e il Web Vulnerability Assessment, che misurano la vostra web app rispetto alle categorie OWASP e vi consegnano un report con priorità d’intervento e contromisure. Contattaci ora per verificare la sicurezza della tua applicazione.


    Dichiaro di aver letto e compreso l'Informativa sul trattamento dei dati