Vulnerabilità delle applicazioni web OWASP Top 10: guida
Le vulnerabilità delle applicazioni web OWASP Top 10 sono le categorie di errori di sicurezza più critiche e diffuse nelle applicazioni web, raccolte dalla fondazione OWASP in un elenco aggiornato periodicamente. Conoscerle aiuta aziende e sviluppatori a capire dove un attaccante colpirà per primo: controllo degli accessi, injection, configurazioni errate, componenti obsoleti. In questa guida le spieghiamo in modo pratico, pensando alle realtà imprenditoriali di Milano.
Cos'è l'OWASP Top 10 e perché riguarda la tua azienda
OWASP (Open Worldwide Application Security Project) è una comunità senza scopo di lucro che produce materiale gratuito sulla sicurezza del software. Il suo documento più noto, la Top 10, è una sintesi dei rischi più rilevanti per le applicazioni web, costruita su dati e contributi del settore.
Non è una norma e non è una checklist completa. È un punto di partenza condiviso, utile per parlare lo stesso linguaggio con sviluppatori, fornitori e consulenti di sicurezza.
Riguarda ogni azienda che ha un sito con area riservata, un e-commerce, un portale clienti, un gestionale accessibile da browser o delle API. Se un'applicazione tratta dati personali, ordini o credenziali, è un bersaglio potenziale.
Differenza tra vulnerabilità ed exploit
Una vulnerabilità è un difetto: un errore di codice, di progettazione o di configurazione. Un exploit è lo strumento o la tecnica che sfrutta quel difetto per ottenere un risultato non previsto, come leggere dati riservati o eseguire comandi.
Il difetto può esistere per anni senza conseguenze. Il rischio nasce quando qualcuno sa come sfruttarlo e può raggiungere l'applicazione. Per un approfondimento generale, puoi leggere la nostra guida su cosa sono le vulnerabilità informatiche e come vengono sfruttate.
Cos'è il CVE e come si collega alla Top 10
Il CVE (Common Vulnerabilities and Exposures) è un sistema di identificazione pubblica delle vulnerabilità note, in cui ogni falla in un prodotto specifico riceve un codice univoco. La Top 10 funziona su un altro piano: descrive famiglie di problemi, non singoli difetti di un singolo software.
Le due cose si incontrano spesso. Un CVE in una libreria o in un CMS può rientrare nella categoria dei componenti vulnerabili e obsoleti.
Le vulnerabilità delle applicazioni web OWASP Top 10: le categorie
Nell'edizione 2021, che è stata a lungo il riferimento principale, le categorie sono queste. Prima di usare l'elenco in un progetto, verifica sul sito OWASP se esiste una versione più recente.
- Broken Access Control: controlli sugli accessi mancanti o aggirabili.
- Cryptographic Failures: dati sensibili protetti male o non protetti.
- Injection: input dell'utente interpretato come comando (include SQL injection e cross site scripting).
- Insecure Design: difetti nella progettazione, non solo nel codice.
- Security Misconfiguration: impostazioni predefinite, servizi inutili, messaggi di errore troppo dettagliati.
- Vulnerable and Outdated Components: librerie e piattaforme non aggiornate.
- Identification and Authentication Failures: gestione debole di password, sessioni e accessi.
- Software and Data Integrity Failures: aggiornamenti e pipeline non verificati.
- Security Logging and Monitoring Failures: attacchi che passano inosservati.
- Server-Side Request Forgery (SSRF): il server viene indotto a fare richieste verso destinazioni non volute.
Ogni voce raggruppa molti difetti diversi. Per questo la lettura corretta è: «in quali di queste aree la mia applicazione è più esposta?».
Come vengono sfruttate nella pratica
Gli attaccanti raramente cercano la falla più sofisticata. Spesso usano scansioni automatiche per individuare applicazioni con difetti noti e poi provano le tecniche più semplici. Vediamo le aree che più spesso fanno la differenza.
Controllo degli accessi e privilege escalation
Il Broken Access Control si verifica quando un utente può fare cose che non dovrebbe: vedere i dati di un altro cliente cambiando un numero nell'indirizzo, oppure raggiungere pagine amministrative senza autorizzazione.
La privilege escalation è l'evoluzione di questo problema: un attaccante parte da un account con pochi permessi e ottiene diritti più alti, fino all'amministrazione. Per prevenirla servono ruoli ben definiti, controlli lato server su ogni richiesta e il principio del privilegio minimo.
SQL injection: cos'è e come difendersi
La SQL injection avviene quando l'applicazione inserisce l'input dell'utente direttamente in una query al database. Un attaccante può così alterare la query, leggere o modificare dati, in alcuni casi aggirare l'autenticazione.
Le difese principali sono query parametrizzate, validazione dell'input, account di database con permessi limitati e messaggi di errore generici. Sono misure ben note, ma richiedono disciplina in tutto il codice, non solo nei punti più evidenti.
Cross site scripting: esempi e prevenzione
Nel cross site scripting (XSS) l'applicazione mostra nel browser contenuti non filtrati, e un attaccante riesce a far eseguire uno script alle vittime. Un esempio tipico è un campo commento o un modulo di ricerca che restituisce il testo inserito senza neutralizzarlo.
Lo script può rubare sessioni, modificare ciò che l'utente vede o reindirizzarlo altrove. La prevenzione si basa sulla codifica dell'output, sulla validazione dell'input e su politiche di sicurezza del browser come la Content Security Policy.
Componenti obsoleti, zero day e ransomware
Molte compromissioni partono da un componente non aggiornato: un plugin, un framework, un software di terze parti. Quando esce un CVE con un exploit pubblico, la corsa tra chi applica la patch e chi la sfrutta è molto rapida.
Una vulnerabilità zero day è un difetto sconosciuto al produttore o ancora privo di correzione, già sfruttato o sfruttabile. Qui la patch non esiste, quindi contano riduzione della superficie esposta, segmentazione, monitoraggio e capacità di reagire in fretta.
I ransomware sfruttano queste debolezze come porta d'ingresso: una falla in un'applicazione esposta su Internet, credenziali rubate o un accesso mal protetto permettono di entrare in rete, muoversi e poi cifrare i dati. L'applicazione web, in questi casi, è l'anello iniziale della catena.
Per esempi di incidenti che hanno coinvolto aziende italiane, conviene consultare fonti ufficiali e aggiornate, come i bollettini del CSIRT Italia e le comunicazioni delle autorità competenti, invece di affidarsi a racconti non verificati.
Come ridurre il rischio: un percorso in cinque passi
- Fai l'inventario delle applicazioni. Non si protegge ciò che non si conosce: siti, portali, API, ambienti di test dimenticati.
- Mantieni aggiornati i componenti. Tieni traccia di librerie, plugin e piattaforme e segui gli avvisi di sicurezza dei produttori.
- Integra la sicurezza nello sviluppo. Revisioni del codice, formazione degli sviluppatori e requisiti di sicurezza fin dalla progettazione.
- Configura e monitora. Disattiva ciò che non serve, proteggi gli accessi amministrativi con autenticazione a più fattori e conserva log utili.
- Verifica con test indipendenti. Un controllo esterno trova ciò che il team interno non vede più.
Come verificare davvero la tua applicazione
Per sapere dove sei esposto servono due strumenti complementari. Il vulnerability assessment individua in modo sistematico le debolezze note e aiuta a stabilire le priorità. Il pentest simula invece l'azione di un attaccante, concatenando i difetti per capire quale impatto reale potrebbero avere.
Chiedi sempre un report chiaro: cosa è stato trovato, quanto è grave, come riprodurlo e come correggerlo. Dopo gli interventi, una verifica di ritest conferma che i problemi siano stati risolti.
Se la tua applicazione tratta dati di clienti o è parte di una filiera, verifica anche i requisiti contrattuali e normativi applicabili al tuo settore.
Conclusione
Le vulnerabilità delle applicazioni web OWASP Top 10 non sono un elenco teorico: descrivono i punti da cui, nella pratica, partono molti attacchi. Capirle, assegnare responsabilità e verificare periodicamente le applicazioni è il modo più concreto per ridurre il rischio.
Se vuoi capire quanto le tue applicazioni siano esposte e quali interventi abbiano la priorità, puoi conoscere approcci e servizi di Fred for Security e valutare con il team il percorso più adatto alla tua realtà.
Domande frequenti
L'OWASP Top 10 è obbligatoria per legge?
No, l'OWASP Top 10 non è una norma di legge ma un riferimento riconosciuto a livello internazionale. Gli obblighi di sicurezza derivano da normative, contratti e requisiti dei clienti, che spesso citano l'OWASP come buona pratica per sviluppo e verifica delle applicazioni.
Se correggo le categorie dell'OWASP Top 10 la mia applicazione è sicura?
No. L'elenco riassume i rischi più diffusi, ma non li esaurisce. Un'applicazione può avere errori di logica di business o problemi specifici dell'infrastruttura che non rientrano nell'elenco. Per questo servono test mirati sul tuo contesto, non solo una checklist.
Ogni quanto conviene testare un'applicazione web?
Non esiste una cadenza valida per tutti. In genere conviene testare prima del rilascio, dopo modifiche importanti all'applicazione o all'infrastruttura e a intervalli regolari definiti in base al rischio, ai dati trattati e a eventuali requisiti normativi o contrattuali.
Chi deve occuparsi dell'OWASP Top 10 in azienda?
È una responsabilità condivisa. Gli sviluppatori correggono il codice, chi gestisce l'infrastruttura cura configurazioni e aggiornamenti, mentre la direzione definisce priorità e risorse. Un partner esterno può fornire verifiche indipendenti e aiutare a trasformare i risultati in un piano di correzione.