Hai un sito web, un portale clienti o un e-commerce? Allora qualcuno, da qualche parte, sta già provando a bucarlo. La OWASP Top 10 è la lista delle 10 vulnerabilità più sfruttate dagli attaccanti, basata su dati reali. In questa guida te le spieghiamo in italiano, con esempi concreti e strategie di difesa, così sai esattamente cosa controllare.
Indice dei Contenuti
Cos'è OWASP e Perché È Importante
OWASP (Open Web Application Security Project) è un'organizzazione no-profit globale nata nel 2001 che si occupa di sicurezza del software. Con oltre 250 capitoli nel mondo e migliaia di volontari, produce strumenti, guide e standard che tutti nel settore usano come riferimento.
Il loro progetto più famoso è la OWASP Top 10: la classifica delle 10 categorie di vulnerabilità più pericolose per le applicazioni web. Viene aggiornata ogni pochi anni analizzando dati reali di centinaia di organizzazioni e milioni di applicazioni testate. L'ultima versione ufficiale è la OWASP Top 10:2021.
Perché OWASP è importante per la tua azienda:
È lo standard de facto per la sicurezza delle applicazioni web in tutto il mondo
È citato da NIS2, GDPR e ISO 27001 come riferimento per le misure tecniche adeguate
I penetration tester usano la metodologia OWASP Testing Guide come framework
Le principali piattaforme (AWS, Azure, Google Cloud) richiedono conformità OWASP
Le cyber insurance verificano la conformità OWASP durante la valutazione del rischio
È gratuito, open source e continuamente aggiornato dalla community globale
Anche se non sviluppi software internamente, la OWASP Top 10 ti riguarda. Se hai un sito, un portale o un e-commerce esposto su Internet, devi verificare che chi te lo ha fatto (o lo gestisce) segua questi standard. Altrimenti è come avere una porta blindata con la serratura aperta.
Le 10 Vulnerabilità OWASP: Descrizione, Esempio e Difesa
Di seguito analizziamo ciascuna delle 10 vulnerabilità OWASP, con una descrizione accessibile, un esempio reale e le strategie di difesa raccomandate.
Broken Access Control
Controllo degli accessi non funzionante
La vulnerabilità più critica del web: gli utenti possono agire al di fuori dei permessi previsti. Include: accesso a dati di altri utenti modificando un ID nell'URL, escalation di privilegi (un utente base che diventa admin), bypass delle restrizioni di accesso manipolando richieste HTTP, accesso a pagine di amministrazione senza autenticazione. Nel 94% delle applicazioni testate sono state trovate forme di broken access control.
Esempio reale
Un dipendente accede al portale clienti e, cambiando l'ID nell'URL da /account/123 a /account/124, visualizza i dati di un altro cliente. Oppure: un utente con ruolo “operatore” modifica una richiesta HTTP e accede al pannello admin con privilegi completi.
Come difendersi
Attivare controlli di accesso lato server (mai solo lato client), negare l'accesso per default (deny by default), verificare i permessi ad ogni richiesta, utilizzare framework di autorizzazione robusti, loggare e monitorare ogni tentativo di accesso non autorizzato.
Cryptographic Failures
Errori nella crittografia
Dati sensibili trasmessi o archiviati senza protezione crittografica adeguata. Include: trasmissione di dati in chiaro (HTTP invece di HTTPS), utilizzo di algoritmi obsoleti (MD5, SHA1, DES), chiavi crittografiche deboli o hardcoded nel codice, certificati SSL/TLS scaduti o mal configurati, password archiviate in chiaro o con hash debole. Questa vulnerabilità porta direttamente a violazioni del GDPR.
Esempio reale
Un'applicazione web aziendale trasmette le credenziali di login su HTTP (non HTTPS). Un attaccante sulla stessa rete (o in una posizione di man-in-the-middle) intercetta username e password di tutti gli utenti. Oppure: il database clienti archivia le password con MD5 senza salt, e in caso di data breach vengono tutte decrittate in minuti.
Come difendersi
Classificare i dati per sensibilità e applicare crittografia adeguata, utilizzare solo HTTPS con TLS 1.2+, attivare HSTS, utilizzare algoritmi moderni (AES-256, bcrypt/Argon2 per le password), gestire le chiavi crittografiche in modo sicuro (HSM o vault), disabilitare la cache per le risposte con dati sensibili.
Injection
Iniezione di codice malevolo
L'applicazione invia dati non fidati a un interprete come parte di un comando o una query. Include: SQL injection (la più nota), NoSQL injection, OS command injection, LDAP injection, XPath injection. Nonostante sia una vulnerabilità nota da oltre 20 anni, rimane tra le più diffuse e devastanti: può portare a lettura, modifica o cancellazione dell'intero database, esecuzione di comandi sul server, e compromissione totale del sistema.
Esempio reale
In un form di login, un attaccante inserisce nel campo password: ' OR '1'='1. Se l'applicazione non sanifica l'input, la query SQL diventa: SELECT * FROM users WHERE password='' OR '1'='1', che è sempre vera, garantendo l'accesso senza conoscere la password. In casi più gravi, l'attaccante può estrarre l'intero database o eseguire comandi sul server.
Come difendersi
Utilizzare query parametrizzate (prepared statements) per OGNI interazione con il database, validare e sanificare tutti gli input utente, applicare il principio del minimo privilegio per l'account database dell'applicazione, utilizzare ORM che gestiscono automaticamente la parametrizzazione, installare un WAF (Web Application Firewall) come livello di difesa aggiuntivo.
Insecure Design
Progettazione non sicura
Difetti nella progettazione dell'architettura dell'applicazione che non possono essere risolti con una implementazione perfetta. A differenza delle altre vulnerabilità (che sono errori di implementazione), l'insecure design è un problema strutturale: l'applicazione è stata progettata senza considerare la sicurezza fin dall'inizio. Include: assenza di rate limiting, mancanza di modellazione delle minacce, nessuna separazione dei privilegi nel design, flussi di business aggirabili.
Esempio reale
Un e-commerce permette di applicare codici sconto senza limite. Un attaccante automatizza la richiesta e applica 100 codici sconto diversi allo stesso ordine, ottenendo il prodotto gratis. Il problema non è un bug nel codice: è che nessuno ha pensato a questo scenario durante la progettazione.
Come difendersi
Integrare la sicurezza fin dalla fase di design (security by design), eseguire threat modeling prima dello sviluppo, definire casi di abuso oltre ai casi d'uso, adottare pattern di design sicuri (defense in depth, fail-safe defaults, least privilege), revisionare l'architettura con esperti di sicurezza prima dello sviluppo.
Security Misconfiguration
Configurazioni di sicurezza errate
La vulnerabilità più comune in assoluto. Include: configurazioni di default non modificate (password admin/admin), funzionalità non necessarie abilitate (porte aperte, servizi inutili), permessi cloud troppo ampi (S3 bucket pubblici), stack trace e messaggi di errore dettagliati visibili agli utenti, header di sicurezza HTTP mancanti, software non aggiornato. Il 90% delle applicazioni ha almeno una misconfiguration.
Esempio reale
Un server web espone la pagina /phpinfo.php che mostra la versione esatta di PHP, i moduli installati e i percorsi del filesystem. Un attaccante usa queste informazioni per trovare exploit specifici per quella versione. Oppure: un database MongoDB è accessibile da Internet senza autenticazione perché è stato installato con le impostazioni predefinite.
Come difendersi
Configurare un processo di hardening ripetibile e documentato, rimuovere funzionalità e componenti non necessari, automatizzare la verifica delle configurazioni (Infrastructure as Code), cambiare tutte le credenziali di default, attivare gli header di sicurezza HTTP (CSP, HSTS, X-Frame-Options), eseguire scansioni di configurazione regolari.
Vulnerable and Outdated Components
Componenti vulnerabili e obsoleti
Utilizzo di librerie, framework o componenti software con vulnerabilità note. Le applicazioni moderne dipendono da decine o centinaia di componenti di terze parti (dipendenze). Se anche uno solo di questi componenti ha una vulnerabilità nota e non viene aggiornato, l'intera applicazione è a rischio. Include: librerie con CVE note non patchate, componenti non più mantenuti (end-of-life), versioni obsolete di framework, dipendenze transitive vulnerabili.
Esempio reale
L'attacco a Log4j (Log4Shell, CVE-2021-44228) ha dimostrato l'impatto devastante di una vulnerabilità in un componente ampiamente utilizzato: milioni di applicazioni erano vulnerabili a Remote Code Execution perché utilizzavano una versione non aggiornata della libreria di logging Log4j. Molte aziende hanno impiegato settimane per identificare tutti i sistemi affetti.
Come difendersi
Mantenere un inventario completo di tutti i componenti e le versioni utilizzate (Software Bill of Materials - SBOM), monitorare le vulnerabilità note (CVE) per ogni componente, attivare un processo di patch management con tempi definiti, utilizzare strumenti di Software Composition Analysis (SCA) nella pipeline CI/CD, rimuovere le dipendenze non utilizzate.
Identification and Authentication Failures
Errori nell'autenticazione
Debolezze nei meccanismi di identificazione e autenticazione degli utenti. Include: assenza di protezione contro attacchi brute force, credenziali deboli permesse (password “123456”), assenza di MFA (autenticazione multi-fattore), session management debole (token prevedibili, sessioni che non scadono), recupero password insicuro. Questa vulnerabilità permette agli attaccanti di impersonare utenti legittimi.
Esempio reale
Un portale aziendale non ha limite ai tentativi di login. Un attaccante esegue un attacco di credential stuffing: prova milioni di combinazioni username/password ottenute da data breach precedenti. Poiché molti dipendenti riutilizzano le stesse password, l'attaccante ottiene accesso a diversi account in poche ore.
Come difendersi
Attivare MFA per tutti gli utenti (non solo gli admin), applicare policy di password robuste (lunghezza minima 12 caratteri, no password comuni), proteggere contro brute force (rate limiting, CAPTCHA, account lockout), utilizzare session management sicuro (token casuali, scadenza, invalidazione al logout), configurare il meccanismo di recupero password in modo sicuro.
Software and Data Integrity Failures
Errori nell'integrità del software e dei dati
L'applicazione non verifica l'integrità del software, degli aggiornamenti o dei dati critici. Include: aggiornamenti automatici senza verifica della firma digitale, dipendenze scaricate da repository non fidati, pipeline CI/CD non protette, deserializzazione insicura di oggetti. Gli attacchi alla supply chain software (come SolarWinds) sfruttano questa categoria di vulnerabilità.
Esempio reale
Un'applicazione aziendale scarica aggiornamenti da un server senza verificare la firma digitale. Un attaccante compromette il server di aggiornamento e distribuisce una versione contenente una backdoor. Tutti i client che si aggiornano vengono compromessi. È esattamente ciò che è successo nell'attacco SolarWinds del 2020.
Come difendersi
Verificare l'integrità di ogni componente con firme digitali o hash, utilizzare solo repository fidati e verificati, proteggere la pipeline CI/CD con controlli di accesso e logging, non deserializzare dati provenienti da fonti non fidate, attivare il code signing per il software distribuito.
Security Logging and Monitoring Failures
Logging e monitoraggio insufficienti
L'applicazione non registra gli eventi di sicurezza o non li monitora. Senza logging adeguato, gli attacchi passano inosservati per settimane o mesi. Secondo IBM, il tempo medio per identificare un data breach è di 204 giorni. Include: login falliti non registrati, errori e anomalie non loggati, log archiviati solo localmente (un attaccante li cancella), nessun alert per attività sospette, nessuna capacità di rilevare attacchi in corso.
Esempio reale
Un attaccante esegue centinaia di tentativi di brute force sull'applicazione web aziendale. Poiché l'applicazione non logga i tentativi di login falliti e non ha alert configurati, nessuno se ne accorge. L'attaccante ottiene le credenziali di un amministratore dopo 3 giorni di attacco e accede ai dati finanziari. L'azienda scopre la violazione solo 4 mesi dopo, durante un audit.
Come difendersi
Loggare tutti gli eventi di sicurezza rilevanti (login, accessi, errori, modifiche ai dati), centralizzare i log in un SIEM (Security Information and Event Management), configurare alert automatici per anomalie e pattern sospetti, attivare un servizio SOC/MDR per il monitoraggio 24/7, proteggere i log dall'alterazione (log immutabili), definire procedure di incident response basate sugli alert.
Server-Side Request Forgery (SSRF)
Falsificazione delle richieste lato server
L'applicazione web effettua richieste HTTP verso URL forniti dall'utente senza validazione adeguata. Un attaccante può forzare il server a effettuare richieste verso risorse interne non altrimenti accessibili. Include: accesso a servizi interni attraverso il server web (bypass del firewall), lettura di metadati cloud (AWS, Azure, GCP) per ottenere credenziali, port scanning della rete interna, accesso a interfacce di amministrazione interne.
Esempio reale
Un'applicazione web ha una funzionalità “anteprima URL” che scarica e visualizza il contenuto di un URL fornito dall'utente. Un attaccante inserisce l'URL http://169.254.169.254/latest/meta-data/iam/security-credentials/ che è il servizio di metadati AWS. Il server, che ha accesso a questo servizio interno, restituisce le credenziali IAM all'attaccante, che ora può accedere all'infrastruttura cloud dell'azienda.
Come difendersi
Validare e sanificare tutti gli URL forniti dagli utenti, configurare una whitelist di domini/IP consentiti, bloccare le richieste verso IP privati e di loopback, segmentare la rete per limitare l'accesso del server web alle risorse interne, disabilitare il servizio di metadati cloud quando non necessario o proteggerlo con IMDSv2 (AWS).
Le Tue Applicazioni Web Sono Vulnerabili?
BullTech esegue Web Application Penetration Test basati sulla metodologia OWASP per identificare e correggere le vulnerabilità delle tue applicazioni.
Parliamone — 039 5787 212OWASP e Compliance: NIS2 e GDPR
La conformità alle OWASP Top 10 non è solo una best practice tecnica: è direttamente collegata ai requisiti delle principali normative europee sulla sicurezza informatica.
NIS2 e OWASP
La NIS2 richiede "pratiche di sviluppo sicuro" e "gestione delle vulnerabilità". Le OWASP Top 10 sono il riferimento più citato per definire cosa significhi "sviluppo sicuro" per le applicazioni web. Verificare la conformità OWASP è una delle azioni più concrete per dimostrare la compliance NIS2.
GDPR e OWASP
Il GDPR richiede "misure tecniche adeguate" per proteggere i dati personali. Se un data breach avviene attraverso una vulnerabilità OWASP nota (injection, broken access control, cryptographic failures), il Garante Privacy valuterà se l'azienda aveva implementato le difese standard. L'assenza di protezioni OWASP può aggravare le sanzioni.
In sintesi: la conformità OWASP è una protezione sia tecnica che legale. Investire nella sicurezza delle applicazioni web secondo gli standard OWASP riduce il rischio di attacco e, nel caso peggiore, dimostra la due diligence richiesta dalle normative. Per approfondire, consulta il nostro servizio di Vulnerability Assessment che include testing OWASP.
Come Applicare OWASP nella Tua Azienda
Applicare le OWASP Top 10 non vuol dire solo correggere i buchi che hai adesso: vuol dire integrare la sicurezza in tutto il ciclo di vita delle tue applicazioni. Ecco un percorso pratico, pensato per PMI italiane:
Inventario delle applicazioni web
IMMEDIATOMappa tutte le applicazioni web della tua azienda: sito, portale clienti, intranet, CRM web, e-commerce, API. Per ciascuna identifica: chi l'ha sviluppata, quando è stata aggiornata l'ultima volta, quali dati gestisce.
Web Application Penetration Test
IMMEDIATOEsegui un pentest OWASP sulle applicazioni più critiche per identificare le vulnerabilità presenti. Utilizza il framework OWASP Testing Guide come riferimento.
Remediation delle vulnerabilità critiche
CRITICOCorreggi le vulnerabilità critiche e alte trovate nel pentest, partendo da quelle con maggiore impatto (injection, broken access control, cryptographic failures).
Implementa un WAF
ALTOInstalla un Web Application Firewall davanti alle applicazioni esposte come livello di protezione aggiuntivo. Un WAF blocca molti attacchi OWASP automatici (injection, XSS, SSRF).
Formazione degli sviluppatori
ALTOSe hai sviluppatori interni o collabori con software house, assicurati che conoscano le OWASP Top 10 e le pratiche di sviluppo sicuro. OWASP offre risorse gratuite eccellenti.
Sicurezza nella pipeline CI/CD
MEDIOIntegra strumenti di analisi automatica (SAST, DAST, SCA) nella pipeline di sviluppo per identificare le vulnerabilità prima che arrivino in produzione (shift-left security).
Se non hai sviluppatori interni, i passi fondamentali sono: fare un checkup OWASP sulle applicazioni web che usi, installare un WAF e verificare che i tuoi fornitori software seguano le pratiche di sviluppo sicuro OWASP. BullTech offre servizi di formazione cybersecurity e analisi di sicurezza specifici per le OWASP Top 10.
Domande Frequenti
Cos'è OWASP e perché è importante per la mia azienda?
OWASP è un'organizzazione no-profit che si occupa di sicurezza del software. Il loro progetto più famoso è la OWASP Top 10: la classifica delle 10 vulnerabilità più pericolose per le applicazioni web, aggiornata con dati reali. Ti riguarda perché: è lo standard di riferimento per la sicurezza web, NIS2 e GDPR lo citano quando parlano di 'misure tecniche adeguate', i tuoi fornitori software dovrebbero seguirlo, e chi fa penetration test lo usa come base.
La OWASP Top 10 si applica solo alle applicazioni web?
La OWASP Top 10 classica si riferisce specificamente alle applicazioni web, ma OWASP pubblica anche altre classifiche specializzate: OWASP Mobile Top 10 (per app mobile), OWASP API Security Top 10 (per le API), OWASP Cloud-Native Application Security Top 10, e OWASP Machine Learning Security Top 10. Se la tua azienda utilizza app mobile, API o servizi cloud, dovresti considerare anche queste classifiche. Il principio resta lo stesso: identificare le vulnerabilità più comuni e prioritizzare le difese.
Come posso verificare se le mie applicazioni sono vulnerabili alle OWASP Top 10?
Il modo migliore è un checkup di sicurezza (Vulnerability Assessment) o un Penetration Test specifico per le tue applicazioni web, fatto da professionisti con la metodologia OWASP Testing Guide. Strumenti automatici come OWASP ZAP (gratuito) o Burp Suite trovano le vulnerabilità più comuni, ma per i problemi di logica serve un'analisi manuale. Per un test completo, ti serve un web application pentest professionale che copra tutte le 10 categorie.
Quanto costa mettere in sicurezza un'applicazione web secondo OWASP?
Dipende da quanto è messa male e da quanto è complessa. Un Penetration Test sulle tue app web costa 4.000-10.000 euro e ti dice dove sono i problemi. Le correzioni variano tantissimo: alcune (configurazioni sbagliate, componenti vecchi) si risolvono in ore, altre (errori di progettazione, controlli accessi rotti) possono richiedere settimane. Regola d'oro: integrare la sicurezza OWASP durante lo sviluppo costa il 70% in meno che correggere tutto quando l'app è già in produzione. Un checkup OWASP completo con correzioni per una PMI costa indicativamente 8.000-25.000 euro.
OWASP è collegato alla compliance NIS2 e GDPR?
Sì, in modo significativo. La NIS2 richiede 'pratiche di sviluppo sicuro' e 'gestione delle vulnerabilità', e la OWASP Top 10 è il riferimento più citato per definire cosa significa 'sviluppo sicuro' per le applicazioni web. Il GDPR richiede 'misure tecniche adeguate' per proteggere i dati personali: se una violazione avviene attraverso una vulnerabilità OWASP nota e non corretta, dimostrare la 'adeguatezza' delle misure diventa molto difficile. In pratica, verificare la conformità alle OWASP Top 10 è considerata una best practice per dimostrare la due diligence sia per NIS2 che per GDPR.
Ogni quanto viene aggiornata la OWASP Top 10?
La OWASP Top 10 viene aggiornata circa ogni 3-4 anni, sulla base dell'analisi di dati reali provenienti da centinaia di organizzazioni. L'ultima versione ufficiale è la OWASP Top 10:2021. Sebbene le categorie specifiche cambino ad ogni aggiornamento (riflettendo l'evoluzione delle minacce), i principi fondamentali restano stabili. Le aziende dovrebbero seguire l'ultima versione pubblicata e monitorare gli aggiornamenti sul sito ufficiale owasp.org. Tra un aggiornamento e l'altro, OWASP pubblica anche draft e ricerche intermedie che anticipano i trend emergenti.
Le OWASP Top 10 sono la base della sicurezza web. Conoscerle e attivare le difese giuste non è facoltativo nel 2026: è un requisito di sicurezza e di compliance. Se non hai mai controllato le tue applicazioni web contro questi standard, scrivici per un checkup dedicato. Il team BullTech opera in tutta la Lombardia dalla sede di Vimercate (Monza Brianza).