OWASP Top 10 2025: cosa cambia e quali rischi uno scanner riesce a rilevare

Che cos'è la OWASP Top 10 2025?

La OWASP Top 10 2025 è una classifica di dieci categorie di rischio per le applicazioni web, ognuna delle quali raggruppa debolezze CWE affini. Per questa edizione OWASP ha analizzato 589 CWE e ne ha tenute 248 nelle dieci categorie, con un tetto di 40 per categoria. Otto categorie vengono dai dati di test donati da aziende come Semgrep, Sonar, Veracode, Contrast Security e Bugcrowd. Le altre due vengono da un sondaggio della community, perché OWASP considera i soli dati incompleti.

I team di sicurezza usano la lista come vocabolario comune. Formazione, checklist di code review, report degli scanner ed evidenze di audit sono spesso organizzati per le sue categorie, ed è per questo che una nuova edizione si fa sentire su strumenti, policy e audit.

Quali sono le dieci categorie?

Le dieci categorie della OWASP Top 10 2025 sono Broken Access Control, Security Misconfiguration, Software Supply Chain Failures, Cryptographic Failures, Injection, Insecure Design, Authentication Failures, Software or Data Integrity Failures, Security Logging and Alerting Failures e Mishandling of Exceptional Conditions. OWASP le pubblica in inglese, e i team le chiamano con quel nome.

Cosa cambia rispetto alla lista del 2021?

Per un team di sviluppo contano quattro cambiamenti: la supply chain ha una sua categoria, la SSRF passa nel controllo degli accessi, la gestione degli errori diventa una categoria e la configurazione errata sale al secondo posto.

• Software Supply Chain Failures (A03). La categoria del 2021, Vulnerable and Outdated Components, copriva le CVE note nelle dipendenze. Quella del 2025 copre i guasti e le compromissioni nel processo di build, distribuzione o aggiornamento del software, e OWASP cita il server di build e la CI/CD fra le cose da proteggere. Una scansione del lockfile non basta più: anche la pipeline che costruisce il tuo codice rientra nel perimetro. Le note di contesto di OWASP danno a questa categoria il tasso di incidenza medio più alto delle dieci.
• La SSRF entra in Broken Access Control (A01). La server-side request forgery era A10 nel 2021. Ora conta come una delle 40 debolezze di Broken Access Control.
• Mishandling of Exceptional Conditions (A10). La nuova categoria riguarda i programmi che non prevengono, non rilevano e non gestiscono le situazioni insolite e imprevedibili. Fra le sue 24 debolezze: messaggi di errore che rivelano dati sensibili (CWE-209), dereferenziazioni di puntatori NULL (CWE-476) e codice che fallisce in modo aperto invece di fallire in modo sicuro (CWE-636).
• Security Misconfiguration (A02) sale dal quinto al secondo posto. La definizione di OWASP ora cita i servizi cloud accanto a sistemi e applicazioni configurati male.

Cambiano due nomi: Identification and Authentication Failures diventa Authentication Failures, e Security Logging and Monitoring Failures diventa Security Logging and Alerting Failures. Il denial of service, ribattezzato Lack of Application Resilience, sta nella sezione "next steps" di OWASP, fuori dalle dieci.

Quale scanner open source rileva ogni rischio?

Gli scanner statici open source coprono in larga parte Injection e Cryptographic Failures, in parte altre sei categorie, e poco di Insecure Design e di Security Logging and Alerting Failures. La tabella è la nostra lettura del perimetro documentato di ogni strumento a confronto con le pagine di categoria di OWASP, lette il 13 novembre 2026.

Opengrep, il fork di Semgrep con licenza LGPL-2.1, copre oltre 30 linguaggi ed esegue le regole Semgrep senza modifiche. Il suo README descrive una taint analysis all'interno di un file, ed è per questo che la riga Injection dice "i flussi che attraversano più file". Trivy legge dipendenze, infrastructure as code, segreti e licenze, e il nostro test degli strumenti SCA open source mostra cosa trovano lui e OSV-Scanner su un lockfile reale. Gitleaks trova password, chiavi API e token nei file e nella cronologia git; le credenziali scritte nel codice (CWE-798) appartengono ad A07 nella lista 2025, e il nostro confronto degli scanner di segreti open source lo tratta a fondo. zizmor è un analizzatore statico per GitHub Actions, con audit come template-injection, unpinned-uses, dangerous-triggers, excessive-permissions e cache-poisoning, che toccano A03 e A08.

Nessuno di questi strumenti vede un pacchetto malevolo che non ha ancora un advisory, la falla da cui passa lo slopsquatting, l'attacco sui nomi di pacchetti inventati da un modello di AI.

Perché gli scanner mancano il rischio numero uno?

Gli scanner statici mancano il cuore di Broken Access Control perché la falla è un controllo assente, e un controllo assente non ha pattern. Uno scanner può seguire l'input dell'utente fino a una funzione pericolosa. Non ha nessuna fonte per la regola secondo cui una fattura appartiene a un solo cliente.

I set di regole lo mostrano. Il 13 novembre 2026 abbiamo contato le regole del set comunitario di Opengrep, un'istantanea delle regole di Semgrep di gennaio 2025: 2.007 regole, di cui 1.354 portano una categoria OWASP del 2021. Injection ne ha 384. Broken Access Control ne ha 228, ma 114 di queste controllano le impostazioni di accesso di risorse cloud, soprattutto in Terraform, e altre coprono path traversal, CSRF e open redirect. Le tre debolezze che descrivono l'autorizzazione vera e propria, CWE-639 (autorizzazione aggirata tramite una chiave controllata dall'utente), CWE-862 (autorizzazione mancante) e CWE-863 (autorizzazione errata), compaiono in quattro regole. Tre di queste leggono codice applicativo, ognuna per un solo framework: un find senza perimetro in Ruby on Rails, un controller ASP.NET Core senza attributo di autorizzazione, operazioni native sui dati in Salesforce Apex. Notano un controllo assente; nessuna sa dire se un controllo presente è quello giusto.

OWASP lo scriveva già nel 2017: gli strumenti SAST e DAST possono rilevare l'assenza di un controllo degli accessi, ma non possono verificare che funzioni quando è presente. Ecco come appare in una route Express:

// GET /api/invoices/:id
app.get("/api/invoices/:id", requireLogin, async (req, res) => {
  const invoice = await db.invoice.findUnique({ where: { id: req.params.id } });
  res.json(invoice);
});

La route richiede il login, la query è parametrizzata, l'input non arriva mai a una funzione pericolosa. Uno scanner non ha niente da segnalare. Eppure qualsiasi cliente autenticato può leggere qualsiasi fattura cambiando il numero nell'URL, un insecure direct object reference. La correzione è una condizione, where: { id: req.params.id, customerId: req.user.customerId }, e può scriverla solo chi sa che le fatture appartengono ai clienti.

Insecure Design è ancora più fuori portata. La pagina di OWASP lo dice chiaramente: un design insicuro non si ripara con un'implementazione perfetta, perché i controlli di sicurezza necessari non sono mai stati creati. Un checkout che accetta una quantità negativa supera ogni scanner, come mostra il nostro percorso nel carrello da zero euro. Trattiamo l'intera famiglia in falle di logica di business nel codice generato dall'AI.

Come si testa il controllo degli accessi?

Il controllo degli accessi si testa con un test che tenta l'azione vietata e si aspetta un rifiuto, uno per ruolo e per ogni oggetto che appartiene a qualcuno. La pagina OWASP del 2025 chiede esattamente questo: sviluppatori e QA dovrebbero includere test funzionali del controllo degli accessi nei loro test unitari e di integrazione.

test("a customer cannot read another customer's invoice", async () => {
  const res = await request(app)
    .get(`/api/invoices/${aliceInvoice.id}`)
    .set("Authorization", tokenFor(bob));
  expect(res.status).toBe(404);
});

Un test così è insieme la prova e la protezione. Prima della correzione fallisce, e questo dimostra che la falla esiste nel tuo codice e non in teoria. Dopo la correzione passa, e resta nella suite perché la prossima modifica non riapra il buco. Il costo è sapere quali oggetti appartengono a chi, che è proprio la conoscenza che manca a uno scanner.

Tre abitudini fanno molta strada:

1. Nega per default. Ogni nuova route nasce chiusa, e l'accesso si concede con un controllo esplicito che nomina il proprietario o il ruolo.
2. Limita ogni query all'utente. Cerca i record passando dall'utente o dal tenant corrente, mai con un identificativo nudo preso dalla richiesta.
3. Un test di rifiuto per ogni oggetto sensibile. Fatture, documenti, account, qualsiasi cosa abbia un proprietario ha un test in cui l'utente sbagliato viene respinto.

Cosa significa la OWASP Top 10 quando sono gli agenti AI a scrivere il codice?

Le categorie non cambiano quando a scrivere il codice sono agenti di coding come Claude Code, Cursor, GitHub Copilot o OpenAI Codex, ma cambiano il volume e la velocità. Un team che rilascia più modifiche a settimana ha bisogno degli scanner su ogni modifica, e ha bisogno che i controlli di accesso vengano rivisti su ogni nuovo endpoint, perché un agente scrive una route funzionante con la stessa facilità con cui salta un controllo sul proprietario che nessuno gli ha mai descritto.

Gli stessi agenti possono anche fare il lavoro difensivo. Un agente che legge il codebase può mappare ogni endpoint, chiedersi quali ruoli raggiungono ciascuno, scrivere il test di rifiuto, eseguirlo e mostrare se fallisce. È la parte della OWASP Top 10 che gli scanner lasciano sul tavolo, ed è un lavoro che un agente di coding può fare alla stessa velocità con cui scrive codice. La nostra guida alla sicurezza degli agenti di coding AI copre l'altro lato: cosa può eseguire l'agente stesso.

Dove si colloca CybeDefend?

CybeDefend Open Source arriva a breve, e copre entrambe le metà di questo articolo. Un comando nel tuo agente di coding, /cybedefend, fa un audit completo in due livelli. Prima gli scanner AppSec, open source, fra cui Opengrep, Trivy, Gitleaks e zizmor, per il codice, le dipendenze, i segreti, l'infrastructure as code, la CI/CD e i container: i rischi a forma di pattern della tabella qui sopra. Tieni quelli che vuoi e aggiungi i tuoi.

Poi lo scanner AI, eseguito dal tuo agente di coding. Gli scanner cercano pattern. Lo scanner AI legge cosa il tuo codice dovrebbe fare e trova dove si rompe, nella logica di business, nei permessi di accesso e nelle falle che emergono solo quando il codice gira: le righe A01, A06 e A07. Dimostra ogni falla con un exploit scritto come test nella tua suite, come quello qui sopra. Nessun modello in più e nessuna chiave API: l'AI è l'agente di coding che usi già.

Sotto i due livelli c'è tutta la nostra piattaforma, un ASPM agentico. Tiene ogni finding in un'unica coda, e i suoi report di sicurezza mappano i finding sulla OWASP Top 10 e sulla CWE Top 25. Per lanciare l'audit sul tuo codice appena apre, iscriviti alla lista d'attesa di CybeDefend Open Source.

Domande frequenti

Quali sono le novità della OWASP Top 10 2025?

Due categorie sono nuove: Software Supply Chain Failures in A03, che estende la vecchia Vulnerable and Outdated Components ai sistemi di build e alla CI/CD, e Mishandling of Exceptional Conditions in A10. La server-side request forgery è passata dentro Broken Access Control, e Security Misconfiguration è salita dal quinto al secondo posto.

Qual è il rischio numero uno della OWASP Top 10 2025?

Broken Access Control, come nel 2021. Raggruppa 40 debolezze, dal path traversal e dal CSRF all'autorizzazione mancante e agli insecure direct object reference, e dal 2025 include anche la SSRF.

La SSRF è ancora nella OWASP Top 10?

Sì, dentro A01 Broken Access Control. Nel 2021 la SSRF era una categoria a sé, A10; l'edizione 2025 l'ha portata nel controllo degli accessi.

Uno strumento SAST basta a coprire tutta la OWASP Top 10?

No. Uno strumento SAST copre bene Injection e Cryptographic Failures e parte di diverse altre categorie. I rischi di dipendenze e pipeline richiedono uno strumento SCA e uno scanner di CI/CD, mentre il controllo degli accessi violato e la progettazione insicura richiedono test e revisione da parte di chi conosce le regole dell'applicazione.

Ogni quanto viene aggiornata la OWASP Top 10?

Non c'è un calendario fisso. L'edizione 2025 è l'ottava, quattro anni dopo la lista del 2021.

CybeDefend è open source?

La sua edizione open source, CybeDefend Open Source, arriva a breve: tutta la nostra piattaforma, un ASPM agentico, gratis sui tuoi server. Il comando /cybedefend concatena gli scanner AppSec open source e uno scanner AI eseguito dal tuo agente di coding, e tiene ogni finding in un'unica coda. Iscriviti alla lista d'attesa di CybeDefend Open Source.