La OWASP Top 10 spiegata agli sviluppatori

#Che cos'è la OWASP Top 10

La OWASP Top 10 è un elenco breve delle dieci categorie di rischio che pesano di più sulle applicazioni web. OWASP, l'Open Worldwide Application Security Project, è un'organizzazione non profit che pubblica gratuitamente indicazioni di sicurezza. L'edizione attuale è quella del 2025, l'ottava della serie.

La Top 10 è un documento di sensibilizzazione. Dà un nome ai difetti che continuano a comparire nelle applicazioni reali, così sviluppatori, tester e manager possono parlarne con le stesse parole. Non è un test, una certificazione né una checklist definitiva.

L'edizione 2025 unisce due tipi di dati. Il primo viene dai test: tredici organizzazioni citate per nome e diversi donatori anonimi hanno comunicato i risultati su oltre 2.8 milioni di applicazioni, contando quante avevano almeno un'istanza di ciascuna debolezza. Il secondo viene dalle vulnerabilità: circa 220.000 record CVE del National Vulnerability Database statunitense, mappati su 643 CWE. I test automatici non vedono tutto, quindi due delle dieci categorie arrivano da un sondaggio della community.

Ogni categoria raggruppa CWE correlati, cioè voci della Common Weakness Enumeration gestita da MITRE. OWASP dice che l'elenco del 2025 copre 248 CWE.

#Perché interessa agli sviluppatori

La maggior parte dei problemi di sicurezza web nasce da poche decisioni che si ripetono. Un'app si fida di un valore inviato dal browser. Una route controlla che l'utente abbia fatto l'accesso ma mai che il record sia suo. Una password viene salvata in un modo che non regge a un leak del database. La Top 10 dà un nome a queste decisioni.

I nomi servono nella pratica. In una revisione del design puoi chiedere dove si decide il controllo degli accessi. In una code review puoi segnalare un controllo di proprietà mancante e citare A01. In un report di incidente puoi descrivere la causa radice invece del sintomo.

#Le dieci categorie

L'ordine è quello dell'edizione 2025. È un ordine di lettura e non dice cosa correggere per primo nella tua app. Ogni sezione riporta un esempio semplice, la difesa principale, i CWE che OWASP associa alla categoria e un cheat sheet.

#A01:2025 Broken Access Control

Il controllo degli accessi stabilisce cosa può fare un utente autenticato. Questa categoria copre le decisioni mancanti, sbagliate o applicate solo nel browser. OWASP riporta che ogni applicazione testata aveva una qualche forma di questo difetto.

Esempio: una pagina d'ordine si carica su /orders/1041. Se cambi il numero in /orders/1042 vedi l'ordine di un altro cliente, perché il server non controlla mai a chi appartiene.

Difesa principale: nega per impostazione predefinita e controlla proprietà e permessi sul server a ogni richiesta, in codice condiviso anziché in ogni handler.

CWE: CWE-284 Improper Access Control, CWE-639 Authorization Bypass Through User-Controlled Key, CWE-862 Missing Authorization, CWE-918 Server-Side Request Forgery (SSRF), tra 40 voci mappate.

Cheat sheet: Authorization Cheat Sheet.

#A02:2025 Security Misconfiguration

Un sistema è sicuro solo quanto lo è la sua configurazione. Questa categoria copre account predefiniti lasciati attivi, funzioni di debug accese, errori troppo dettagliati, header di sicurezza mancanti e storage cloud con i permessi sbagliati.

Esempio: un server di staging gira con la password admin predefinita della guida di installazione e mostra stack trace completi a qualsiasi visitatore.

Difesa principale: usa un processo di hardening ripetibile. Configura sviluppo, QA e produzione allo stesso modo, con credenziali diverse in ciascuno, e togli le funzioni e gli esempi che non usi.

CWE: CWE-16 Configuration, CWE-260 Password in Configuration File, CWE-15 External Control of System or Configuration Setting, tra 16 voci mappate.

Riferimento: capitolo V13 Configuration di ASVS. OWASP non indica alcun cheat sheet per questa categoria.

#A03:2025 Software Supply Chain Failures

La tua applicazione esegue codice che non hai scritto tu. Questa categoria copre il percorso del software dal sorgente alla produzione: dipendenze, strumenti di build, registri e canali di aggiornamento. OWASP nota che la categoria si è estesa oltre i componenti con vulnerabilità note e che è arrivata prima nel sondaggio della community.

Esempio: un piccolo pacchetto di utilità nel tuo albero delle dipendenze viene sostituito da una versione con codice malevolo, e la build successiva lo installa.

Difesa principale: devi sapere cosa distribuisci. Genera una software bill of materials (SBOM), tieni traccia delle dipendenze transitive, rimuovi i pacchetti inutilizzati e tieni aggiornato l'inventario dei componenti.

CWE: CWE-1104 Use of Unmaintained Third Party Components, CWE-1395 Dependency on Vulnerable Third-Party Component e altre quattro voci mappate.

Cheat sheet: Vulnerable Dependency Management Cheat Sheet e Dependency Graph SBOM Cheat Sheet.

#A04:2025 Cryptographic Failures

Questa categoria copre crittografia assente, algoritmi deboli, cattiva gestione delle chiavi e controlli sui certificati saltati. L'errore tipico è spesso una decisione mai presa più che un algoritmo rotto: i dati viaggiano su HTTP in chiaro, o restano in uno storage che nessuno ha controllato.

Esempio: un modulo di accesso invia le password su HTTP in chiaro, oppure le salva con un hash veloce e senza salt.

Difesa principale: prima classifica i dati, poi decidi cosa va cifrato in transito e a riposo. Usa implementazioni affidabili di algoritmi standard e non conservare dati sensibili che non ti servono.

CWE: CWE-261 Weak Encoding for Password, CWE-319 Cleartext Transmission of Sensitive Information, CWE-321 Use of Hard-coded Cryptographic Key, tra 32 voci mappate.

Cheat sheet: Transport Layer Protection Cheat Sheet e Password Storage Cheat Sheet.

#A05:2025 Injection

Un'injection avviene quando un input non attendibile raggiunge un interprete, come un motore SQL, una shell del sistema operativo o un browser, e l'interprete esegue parte di quell'input come istruzioni. OWASP elenca come forme comuni le injection SQL, NoSQL, di comandi del sistema operativo, ORM, LDAP e di expression language. Nell'edizione 2025 rientra in questa categoria anche il cross-site scripting (XSS).

Esempio: un handler di ricerca concatena il testo dell'utente in una stringa SQL. Un apice in quel testo cambia il significato della query.

Difesa principale: usa un'API sicura che tenga i dati separati dai comandi, come le query parametrizzate o un ORM. Valida l'input sul server con allow list. Dove l'output dinamico è inevitabile, applica le regole di escaping dell'interprete di destinazione. Con i nomi di tabelle e colonne l'escaping non funziona, quindi tienili del tutto fuori dall'input dell'utente.

CWE: CWE-20 Improper Input Validation, CWE-74 Injection, CWE-78 OS Command Injection, CWE-79 Cross-site Scripting, tra 37 voci mappate.

Cheat sheet: Injection Prevention Cheat Sheet e SQL Injection Prevention Cheat Sheet.

#A06:2025 Insecure Design

Nessuna implementazione può correggere un design che non ha mai previsto una difesa. Questa categoria copre i controlli mai pianificati: logica di business abusabile, flussi di recupero che si affidano a risposte indovinabili, privilegi concessi per impostazione predefinita.

Esempio: un endpoint di sconti accetta lo stesso coupon più volte, perché nessuno ha considerato il riuso come una minaccia.

Difesa principale: fai il threat model dei flussi critici, come autenticazione, controllo degli accessi e pagamenti, prima di costruirli. L'articolo sul threat modeling mostra un modo per porre queste domande. Riusa pattern di design sicuro già collaudati invece di inventarne uno nuovo per ogni funzione.

CWE: CWE-269 Improper Privilege Management, CWE-256 Unprotected Storage of Credentials, CWE-73 External Control of File Name or Path, tra 39 voci mappate.

Cheat sheet: Secure Product Design Cheat Sheet.

#A07:2025 Authentication Failures

Questi difetti fanno entrare la persona sbagliata, o lasciano che un attaccante continui a provare finché un tentativo riesce. Comprendono credential stuffing, password spraying, recupero account debole, autenticazione a più fattori (MFA) assente e sessioni che restano valide dopo il logout.

Esempio: un login admin non ha limite di richieste né MFA. Un attaccante prova coppie di nome utente e password prese da violazioni precedenti finché una funziona.

Difesa principale: imponi la MFA dove puoi, blocca i tentativi automatici, rimuovi gli account predefiniti e confronta le nuove password con un elenco di quelle comuni. OWASP suggerisce le 10.000 password peggiori.

CWE: CWE-287 Improper Authentication, CWE-259 Use of Hard-coded Password, CWE-290 Authentication Bypass by Spoofing, tra 36 voci mappate.

Cheat sheet: Authentication Cheat Sheet.

#A08:2025 Software or Data Integrity Failures

Integrità significa che codice o dati sono quelli che ti aspetti e nessuno li ha modificati lungo la strada. Questa categoria copre aggiornamenti automatici senza verifica della firma, script caricati da una CDN senza controllo di integrità, pipeline CI/CD che prendono artefatti da posti non verificati e deserializzazione di oggetti non attendibili.

Esempio: una pagina carica un file JavaScript da una CDN di terze parti senza attributo integrity. Se quel file viene modificato, ogni visitatore esegue il codice modificato.

Difesa principale: firma ciò che distribuisci e verifica la firma prima dell'uso. Limita i package manager a repository attendibili e richiedi una review per le modifiche a pipeline e configurazione.

CWE: CWE-345 Insufficient Verification of Data Authenticity, CWE-494 Download of Code Without Integrity Check, CWE-502 Deserialization of Untrusted Data, tra 14 voci mappate.

Cheat sheet: Software Supply Chain Security Cheat Sheet.

#A09:2025 Security Logging and Alerting Failures

Senza log e alert, una violazione può andare avanti per mesi senza che nessuno la veda. Questa categoria copre la mancata registrazione dei login e dei fallimenti del controllo degli accessi, log tenuti solo su una macchina che può essere compromessa, alert che nessuno legge e log che espongono segreti.

Esempio: i login falliti di un account admin non vengono mai registrati, e la riga di log di un reset password contiene la nuova password.

Difesa principale: registra i fallimenti di autenticazione e di controllo degli accessi con contesto sufficiente per indagare, codifica i dati prima di scriverli nel log, tieni i segreti fuori dai log e invia i log in un posto che l'host dell'applicazione non può riscrivere.

CWE: CWE-778 Insufficient Logging, CWE-532 Insertion of Sensitive Information into Log File, CWE-117 Improper Output Neutralization for Logs, tra 5 voci mappate.

Cheat sheet: Logging Cheat Sheet e Application Logging Vocabulary Cheat Sheet.

#A10:2025 Mishandling of Exceptional Conditions

Il software fallisce. Questa categoria riguarda come fallisce: un crash che espone dati, un controllo saltato perché una chiamata ha restituito un errore, un'operazione a più passaggi che prosegue dopo il fallimento di uno di essi.

Esempio: una chiamata di pagamento va in timeout, il codice tratta il timeout come un successo e l'ordine parte senza essere pagato.

Difesa principale: intercetta gli errori dove si verificano e gestiscili di proposito. Aggiungi un gestore globale delle eccezioni come rete di sicurezza. Quando un'operazione a più passaggi fallisce a metà, fai il rollback e vai in fail closed.

CWE: CWE-209 Generation of Error Message Containing Sensitive Information, CWE-252 Unchecked Return Value, CWE-248 Uncaught Exception, tra 24 voci mappate.

Cheat sheet: Error Handling Cheat Sheet.

#Cosa non è la Top 10

Non è uno standard completo. Dieci categorie non possono descrivere ogni requisito di un'applicazione sicura, e molti rischi restano fuori dall'elenco. Superare una review sulla Top 10 non rende sicura un'applicazione.

Non è una checklist che si può finire. Le categorie descrivono cause, quindi una funzione può toccarne diverse e una categoria comprende molti bug diversi. I team che la trattano come una casella da spuntare spesso correggono gli esempi e tengono il pattern che li ha prodotti.

Non è il posto dove stanno i requisiti. Per quelli OWASP pubblica l'Application Security Verification Standard (ASVS), un insieme di requisiti di sicurezza per progettare, costruire e testare applicazioni e servizi web. La versione attuale è la 5.0.0, pubblicata il 30 maggio 2025. Usa la Top 10 per spiegare il rischio e decidere da dove cominciare a guardare. Usa ASVS quando ti servono requisiti da implementare e verificare.

#Come usare l'elenco su una funzione reale

1. Scegli una funzione, come il login, il checkout o il caricamento di file.
2. Scorri le dieci categorie e annota quali si applicano.
3. Per ciascuna, indica il controllo nel tuo design e il test che lo dimostra. Se usi ASVS, registra l'ID del requisito.
4. Registra il risultato nel threat model o nel backlog, con categoria e CWE oltre al titolo del bug. Ripeti la review dopo le modifiche a dipendenze e deploy, perché A02, A03 e A08 cambiano con l'ambiente.

#Lab pratico: collega tre categorie di Juice Shop

Eseguirai OWASP Juice Shop, un'applicazione web volutamente vulnerabile, sulla tua macchina. Leggerai lo scoreboard e collegherai tre categorie di sfide alle voci della Top 10. Non sfrutterai nulla. Leggi le descrizioni delle sfide e non le soluzioni, e tieni l'app legata a localhost.

Ti serve Docker. L'output qui sotto viene da Docker 29.8.2 su Windows 11 con Git Bash. I comandi funzionano in qualsiasi shell POSIX.

#Passo 1: controlla Docker

docker --version
docker info --format '{{.ServerVersion}}'

Output osservato:

Docker version 29.8.2, build 7fc2dff
29.8.2

#Passo 2: avvia Juice Shop solo su loopback

docker run -d -p 127.0.0.1:3000:3000 bkimminich/juice-shop

Il prefisso 127.0.0.1: pubblica la porta solo sull'interfaccia di loopback, quindi le altre macchine non possono raggiungerla. Sulla macchina dove ho eseguito questi passaggi, un container della stessa immagine era già in esecuzione come juice-local, quindi non ne ho avviato un secondo. Controlla cosa è in esecuzione:

docker ps --format '{{.Names}} {{.Image}} {{.Ports}}'

La riga di Juice Shop nell'output osservato:

juice-local bkimminich/juice-shop 127.0.0.1:3000->3000/tcp

#Passo 3: controlla che l'app risponda

curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:3000/
curl -s http://127.0.0.1:3000/rest/admin/application-version

Output osservato:

200
{"version":"20.3.0"}

La tua versione può essere diversa. Annotala, perché nomi e categorie delle sfide cambiano da una release all'altra.

#Passo 4: conta le sfide per categoria

curl -s http://127.0.0.1:3000/api/Challenges/ -o challenges.json
python -c "import json,collections; d=json.load(open('challenges.json'))['data']; print(len(d)); [print(v,k) for k,v in sorted(collections.Counter(x['category'] for x in d).items())]"

Output osservato:

116
12 Broken Access Control
4 Broken Anti Automation
9 Broken Authentication
5 Cryptographic Issues
12 Improper Input Validation
14 Injection
3 Insecure Deserialization
6 Miscellaneous
4 Observability Failures
5 Security Misconfiguration
3 Security through Obscurity
17 Sensitive Data Exposure
2 Unvalidated Redirects
9 Vulnerable Components
9 XSS
2 XXE

#Passo 5: apri lo scoreboard

Apri http://127.0.0.1:3000/#/score-board nel browser e confronta le categorie con i conteggi qui sopra. Se i numeri sono diversi, annota la versione di Juice Shop.

#Passo 6: collega tre categorie alla Top 10

Questa è una mappatura ragionevole. La tua può essere diversa, se sai giustificarla in una frase.

Perché ogni riga regge:

• A01. Il controllo che decide chi può raggiungere un'area di amministrazione è assente o sbagliato, e la sfida indica proprio quell'area come obiettivo.
• A05. La categoria riguarda input non attendibile che raggiunge un interprete. La descrizione non nomina l'interprete, quindi dichiara che hai collegato la categoria e non una tecnica specifica.
• A02. Output e gestione degli errori sono scelte di configurazione. Lo stesso comportamento corrisponde anche ad A10, perché nell'edizione 2025 CWE-209 è elencato sotto A10. Indica quale voce hai scelto e perché.

I nomi delle categorie di Juice Shop sono etichette sue. La categoria XSS, per esempio, corrisponde ad A05 nell'elenco del 2025. Mappa in base alla causa radice e cita il CWE.

#Passo 7: ferma e rimuovi il lab

docker ps --format '{{.Names}} {{.Image}}'
docker stop <container-name>
docker rm <container-name>

Sostituisci <container-name> con il nome dato dal primo comando. Il container è stato avviato con -d e senza --rm, quindi dopo l'arresto resta su disco finché non lo rimuovi.

#Errori comuni

• Leggere l'elenco come completo. Molti rischi non compaiono mai come categoria. Usa ASVS quando ti servono requisiti.
• Mappare in base al titolo del bug. Mappa in base alla causa radice e cita il CWE. Un titolo come "XSS" ti porta a un CWE, e da lì arriva la categoria.
• Correggere l'esempio e tenere il pattern. Se l'endpoint di cancellazione controlla la proprietà e quello di modifica no, A01 resta aperta.
• Esporre un lab. Pubblicare Juice Shop su 0.0.0.0 o su un host cloud mette su internet un'applicazione volutamente vulnerabile.
• Testare fuori dal lab. Scansioni e passaggi d'attacco vanno solo su sistemi tuoi o che hai il permesso di testare.
• Scrivere segreti nei log durante il debug. A09 comprende i log che espongono credenziali, e succede facilmente mentre cerchi un problema.

#Per andare oltre

• Leggi i capitoli ASVS che corrispondono alle tue categorie. Per il controllo degli accessi, inizia da ASVS V8 Authorization.
• Leggi i cheat sheet indicati in ogni sezione. Sono brevi e scritti per chi implementa i controlli.
• Apri le pagine CWE delle debolezze che il tuo codice ha davvero.
• Poi affronta SQL injection spiegata con Juice Shop, che porta avanti la categoria Injection nello stesso lab.

#Fonti

• OWASP Top 10:2025, https://owasp.org/Top10/ (reindirizza a https://top10.owasp.org/)
• OWASP Application Security Verification Standard, https://owasp.org/www-project-application-security-verification-standard/
• OWASP Cheat Sheet Series, https://cheatsheetseries.owasp.org/
• MITRE Common Weakness Enumeration, https://cwe.mitre.org/
• OWASP Juice Shop project, https://owasp.org/www-project-juice-shop/
• Docker port publishing, https://docs.docker.com/engine/network/port-publishing/