Due liste, un solo budget di sicurezza applicativa. Nel 2025 OWASP ha pubblicato due aggiornamenti importanti nello stesso ciclo: la nuova OWASP Top 10:2025 per le applicazioni web in generale e la OWASP API Security Top 10:2025, dedicata esclusivamente alle API. Per un CISO o un team di sviluppo in Italia, la domanda pratica non è quale lista sia “più giusta”, ma quale usare per dare priorità alle patch, ai test e ai controlli quando il tempo e i soldi non bastano mai per tutto.
Questo confronto mette le due liste fianco a fianco, con le categorie aggiornate, i dati di incidenti reali raccolti da ENISA nel Threat Landscape 2025, e una guida pratica su quando applicare l’una, l’altra, o entrambe. Lo scriviamo per chi deve decidere davvero, non per chi vuole solo un elenco da stampare.
Il contesto conta. Le banche italiane, le utility e la pubblica amministrazione hanno spostato negli ultimi anni gran parte dei loro servizi dietro API: app di home banking, portali INPS e Agenzia delle Entrate, marketplace di e-commerce con integrazioni di pagamento. Ogni endpoint aggiunto è una nuova riga nella superficie d’attacco, e la scelta tra le due liste OWASP non è un esercizio accademico ma decide dove va il primo euro del budget di sicurezza applicativa.
Cosa sono OWASP Top 10 e OWASP API Security Top 10
OWASP (Open Worldwide Application Security Project) mantiene da anni due progetti distinti. La OWASP Top 10:2025 è la lista generalista, pensata per qualsiasi applicazione web: siti aziendali, portali pubblici, backend monolitici, e-commerce. È la versione più recente del progetto storico, presentata alla OWASP Global AppSec Conference di fine 2025 a Washington DC, e sostituisce l’edizione 2021.
La OWASP API Security Top 10, aggiornata anch’essa al 2025, nasce invece per un problema specifico: le API REST, GraphQL e RPC hanno superfici di attacco che le liste generaliste non catturano bene. Un endpoint come /api/v1/users/12345/profile che restituisce dati di un altro utente senza controllare i permessi non è un problema di injection o XSS: è un problema di autorizzazione a livello di oggetto, categoria che nella lista generale finisce dentro “Broken Access Control” ma che nella lista API ha una voce dedicata e più operativa.
Non è un dettaglio da poco per chi lavora tutti i giorni con codice: un’applicazione web tradizionale nasconde molti parametri dietro form HTML, sessioni server-side e redirect, mentre un’API espone la sua interfaccia in modo esplicito, spesso documentata pubblicamente in uno schema OpenAPI. Questo rende più facile per un attaccante capire cosa provare, ma rende anche più facile per un difensore automatizzare i test, a patto di usare gli strumenti giusti e sapere quali categorie di rischio cercare.
La differenza pratica: la Top 10 generale guarda al ciclo di vita completo di un’applicazione (configurazione, crittografia, supply chain, logging), mentre la Top 10 API si concentra sui pattern di abuso specifici di endpoint programmabili, spesso privi di interfaccia utente che nasconda i parametri manipolabili. Molti team che lavorano su architetture a microservizi finiscono per usare entrambe insieme, mappandole sullo stesso framework di controllo.
Vale la pena ricordare che entrambi i progetti sono mantenuti da OWASP Foundation, organizzazione no-profit che coordina centinaia di volontari a livello globale e non vende certificazioni o licenze. Questo è uno dei motivi per cui le due liste, pur essendo pubblicate da team diversi all’interno della stessa fondazione, vengono aggiornate con cicli e velocità differenti: la Top 10 generale segue un ciclo pluriennale legato alle grandi conferenze AppSec, mentre la lista API viene aggiornata quando il gruppo di lavoro raccoglie abbastanza segnalazioni da giustificare una revisione delle categorie.
Un esempio concreto rende la differenza tra le due liste più tangibile. Il blocco di codice seguente mostra un endpoint vulnerabile a BOLA (API1:2025) e la correzione minima che introduce il controllo di autorizzazione mancante.
// Vulnerabile: nessun controllo che l'utente autenticato
// sia il proprietario del profilo richiesto (API1:2025 - BOLA)
app.get('/api/v1/users/:id/profile', async (req, res) => {
const profile = await db.getProfile(req.params.id);
res.json(profile);
});
// Corretto: verifica che l'ID richiesto corrisponda
// all'utente autenticato nel token, o che abbia un ruolo autorizzato
app.get('/api/v1/users/:id/profile', authenticate, async (req, res) => {
if (req.user.id !== req.params.id && !req.user.roles.includes('admin')) {
return res.status(403).json({ error: 'Accesso negato' });
}
const profile = await db.getProfile(req.params.id);
res.json(profile);
});Questo pattern di vulnerabilità, banale da spiegare ma frequente da trovare in produzione, è il motivo per cui BOLA resta la voce numero uno di entrambe le edizioni consecutive della API Security Top 10: non richiede un attacco sofisticato, basta cambiare un numero nell’URL.
Le 10 categorie della OWASP Top 10:2025
La revisione 2025 ha spostato parecchio le carte in tavola rispetto all’edizione 2021. Secondo l’analisi pubblicata da Qualys sul confronto tra le edizioni 2021 e 2025, la Security Misconfiguration è salita dal quinto al secondo posto, e la Software Supply Chain Failures è entrata come categoria nuova al terzo posto, con il tasso di incidenza più alto tra le new entry.
| Codice | Categoria OWASP Top 10:2025 | Variazione vs 2021 |
|---|---|---|
| A01:2025 | Broken Access Control | Confermata al primo posto, ora include BOLA e BFLA |
| A02:2025 | Security Misconfiguration | Sale dal 5° al 2° posto |
| A03:2025 | Software Supply Chain Failures | Nuova categoria |
| A04:2025 | Cryptographic Failures | Scende di una posizione |
| A05:2025 | Injection | Scende, ma resta rilevante |
| A06:2025 | Insecure Design | Stabile |
| A07:2025 | Authentication Failures | Rinominata da “Identification and Authentication Failures” |
| A08:2025 | Software or Data Integrity Failures | Stabile |
| A09:2025 | Logging and Alerting Failures | Rinominata, focus su alerting |
| A10:2025 | Mishandling of Exceptional Conditions | Nuova categoria |
Un dettaglio che i team italiani spesso trascurano: la SSRF (Server-Side Request Forgery), che nell’edizione precedente aveva una voce quasi autonoma, è stata assorbita dentro Broken Access Control (A01:2025), secondo quanto riportato da NordicAPIs. Chi aveva creato regole di detection separate per SSRF deve rivedere la mappatura, non solo aggiornare i nomi delle categorie.
Le 10 categorie della OWASP API Security Top 10:2025
Sul fronte API, la struttura del 2025 mantiene la logica dell’edizione precedente ma consolida diverse voci. Secondo l’analisi comparativa pubblicata da AST Database, la BOLA resta al primo posto senza cambiamenti, confermandosi la falla più comune negli endpoint pubblici.
| Codice | Categoria API Security Top 10:2025 | Nota pratica |
|---|---|---|
| API1:2025 | Broken Object Level Authorization (BOLA) | Invariata, resta la falla più frequente |
| API2:2025 | Broken Authentication | Errori JWT e MFA mancante dominano ancora |
| API3:2025 | Broken Object Property Level Authorization | Fonde le vecchie Excessive Data Exposure e Mass Assignment |
| API4:2025 | Unrestricted Resource Consumption | Estende il vecchio “Lack of Rate Limiting” |
| API5:2025 | Broken Function Level Authorization | Stabile |
| API6:2025 | Unrestricted Access to Sensitive Business Flows | Focus su abusi di logica di business (es. checkout) |
| API7:2025 | Server-Side Request Forgery (SSRF) | Voce autonoma, a differenza della Top 10 generale |
| API8:2025 | Security Misconfiguration | CORS permissivo, credenziali di default, debug attivo |
| API9:2025 | Improper Inventory Management | Versioni API deprecate ancora attive fuori dal perimetro protetto |
| API10:2025 | Unsafe Consumption of APIs | Rischio di fiducia eccessiva verso API di terze parti |
Da notare: SSRF resta una categoria propria (API7:2025) nella lista API, mentre nella Top 10 generale è stata inglobata in Broken Access Control. È uno dei punti in cui le due liste divergono davvero, non solo nel nome.
Tabella comparativa diretta: dove si sovrappongono e dove no
La tabella seguente mette a confronto le due liste categoria per categoria, indicando dove i concetti coincidono e dove invece una lista copre uno scenario che l’altra tratta in modo diverso o non tratta affatto.
| Rischio | OWASP Top 10:2025 | API Security Top 10:2025 | Sovrapposizione |
|---|---|---|---|
| Controllo accessi rotto | A01 Broken Access Control | API1 BOLA, API5 Broken Function Level Auth | Alta, ma l’API list è più granulare |
| Configurazioni errate | A02 Security Misconfiguration | API8 Security Misconfiguration | Diretta, stesso concetto |
| Supply chain | A03 Software Supply Chain Failures | API10 Unsafe Consumption of APIs | Parziale: A03 guarda a dipendenze e CI/CD, API10 a fiducia verso API esterne |
| Crittografia | A04 Cryptographic Failures | Non ha voce dedicata | Bassa, coperta solo dalla lista generale |
| Injection | A05 Injection | Non ha voce dedicata | Bassa, ma implicita in più categorie API |
| Autenticazione | A07 Authentication Failures | API2 Broken Authentication | Diretta |
| Esposizione dati eccessiva | Non ha voce dedicata | API3 Broken Object Property Level Authorization | Solo nella lista API |
| Rate limiting e DoS applicativo | Non ha voce dedicata | API4 Unrestricted Resource Consumption | Solo nella lista API |
| Abuso di logica di business | A06 Insecure Design (generico) | API6 Unrestricted Access to Sensitive Business Flows | Parziale, l’API list è più operativa |
| SSRF | Assorbita in A01 | API7 voce propria | Divergente |
| Inventario e versioning | Non ha voce dedicata | API9 Improper Inventory Management | Solo nella lista API |
| Logging e alerting | A09 Logging and Alerting Failures | Non ha voce dedicata | Solo nella lista generale |
Il quadro che emerge è chiaro: circa metà delle categorie si sovrappongono direttamente, mentre l’altra metà copre rischi che una lista vede e l’altra no. Non è un caso di ridondanza: sono due lenti diverse sullo stesso perimetro applicativo, e chi ne usa solo una lascia scoperto un pezzo di superficie d’attacco.
Le quattro righe della tabella dove la sovrapposizione è “solo nella lista API” (esposizione dati eccessiva, rate limiting, inventario, e in parte l’abuso di logica di business) sono probabilmente il valore aggiunto più concreto della lista API Security per un team che già segue la Top 10 generale da anni. Sono rischi che un audit generico, per quanto ben fatto, tende a non catturare perché richiedono di ragionare endpoint per endpoint, non pagina per pagina.
Cosa dicono i dati di incidenti reali
Il report ENISA Threat Landscape 2025 ha analizzato 4.875 incidenti raccolti tra il 1° luglio 2024 e il 30 giugno 2025 in tutta Europa. Una quota rilevante di questi eventi viene mappata sulla tecnica MITRE ATT&CK T1190, “Exploitation of Public-Facing Application”, che copre sia applicazioni web tradizionali sia endpoint API esposti pubblicamente.
Il dato interessante per chi lavora in Italia è che ENISA sottolinea come misconfigurazioni e falle di autenticazione/autorizzazione dominino gli attacchi riusciti contro servizi pubblici in Europa. Questo si sovrappone direttamente con A01 e A02 della Top 10 generale e con API1, API2, API8 della lista API: i dati reali confermano che le categorie più in alto nelle classifiche OWASP non sono teoria, sono quello che succede davvero.
Uno studio del 2025 sui pattern degli API gateway, citato dalla rivista accademica SCRD, ha misurato che i gateway API moderni possono mitigare in modo sistematico almeno le prime cinque categorie della OWASP API Security Top 10 (API1-API5) quando configurati correttamente, imponendo controlli di autorizzazione a livello di oggetto, rate limiting centralizzato e controllo degli accessi a livello di funzione. Lo stesso studio nota però che i gateway sono meno efficaci contro problemi di design, come API6 (abuso di flussi di business), a meno che gli sviluppatori non modellino esplicitamente le regole di business nel livello applicativo.
Un altro elemento che emerge dal report ENISA riguarda la distribuzione settoriale degli incidenti: pubblica amministrazione, finanza e sanità restano i tre settori più colpiti a livello europeo, e sono anche i tre settori dove l’esposizione di API è cresciuta più rapidamente negli ultimi due anni. Per un’organizzazione italiana che opera in uno di questi comparti, questo significa che la mappatura delle categorie API non è solo una buona pratica tecnica, ma un elemento che finisce direttamente nei report di audit richiesti da Banca d’Italia o dal Garante Privacy in caso di incidente.
Il contesto normativo europeo: NIS2, GDPR e Cyber Resilience Act
Per i lettori italiani, il motivo per cui questa scelta tra due liste OWASP conta davvero è normativo tanto quanto tecnico. La direttiva NIS2, recepita in Italia, impone a un perimetro molto più ampio di aziende (non solo infrastrutture critiche, ma anche fornitori di servizi digitali di medie dimensioni) obblighi di gestione del rischio che includono esplicitamente la sicurezza della catena di fornitura software, uno dei temi centrali della nuova categoria A03:2025 Software Supply Chain Failures.
Il Cyber Resilience Act, che introduce requisiti di sicurezza by design per i prodotti con componenti digitali venduti nell’UE, spinge nella stessa direzione: ENISA ha lanciato alla fine del 2025 un’indagine per raccogliere dati fattuali su come le organizzazioni europee stiano adottando gli SBOM (Software Bill of Materials), lo strumento chiave per rendere verificabile la catena di fornitura software richiesta dal CRA. Chi lavora già con la categoria A03:2025 della Top 10 generale ha un vantaggio concreto nel dimostrare conformità.
Sul fronte GDPR, il collegamento è più diretto con la lista API: una violazione BOLA (API1:2025) che espone dati personali di altri utenti è, quasi per definizione, una violazione che richiede notifica al Garante Privacy entro 72 ore se comporta un rischio per i diritti e le libertà delle persone fisiche. Le organizzazioni che gestiscono dati sanitari o finanziari tramite API dovrebbero considerare API1 e API3 (esposizione eccessiva di proprietà degli oggetti) come priorità assolute proprio per il collegamento diretto con gli obblighi di notifica.
Per i team legal e compliance che collaborano con gli sviluppatori, un consiglio pratico: chiedere sempre quale delle due liste OWASP è stata usata come riferimento in un penetration test o in un audit di sicurezza commissionato a terzi. Un report che cita solo la Top 10 generale su un’applicazione API-first può dare un falso senso di sicurezza, perché lascia fuori dal perimetro di test proprio le categorie (BOLA, business flow abuse, inventario) dove si concentrano gli incidenti più costosi in termini di esposizione dati personali.
Benchmark: cosa rilevano gli scanner sulle due liste
Non esiste ancora un benchmark unico e universalmente citato che confronti il “tasso di rilevamento” scanner per scanner sulle due liste, ma tre fonti indipendenti offrono un quadro convergente utile per capire dove concentrare gli sforzi di test.
- Qualys TotalAppSec (analisi pubblicata giugno 2026): la categoria A02 Security Misconfiguration è quella con il maggior numero di rilevazioni automatizzate nei tenant scansionati, superando Injection per la prima volta da quando esiste la Top 10.
- CAI Tech (checklist API pubblicata 2026): negli endpoint REST testati, BOLA (API1) resta la falla più frequente in assoluto, riscontrata più spesso di qualsiasi altra categoria API, confermando il trend già osservato nell’edizione 2023 della lista.
- NordicAPIs: la migrazione della SSRF da voce autonoma a sottocategoria di Broken Access Control nella lista generale ha ridotto la visibilità del rischio nei report automatizzati che si basano sui codici categoria OWASP per la classificazione, un effetto collaterale da tenere presente quando si configurano le dashboard SAST/DAST.
Il filo conduttore tra le tre fonti: i problemi di configurazione e di autorizzazione restano, anno dopo anno, la causa più comune di incidenti rilevabili, molto più delle classiche injection che dominavano i benchmark di dieci anni fa. Per chi deve giustificare un investimento in strumenti di test automatizzati davanti a un management che guarda ai numeri, questo è l’argomento più solido: non si tratta di rincorrere una moda della sicurezza, ma di seguire dove i dati mostrano che gli attacchi riescono davvero.
Pricing e costi di adozione: strumenti, tempo, formazione
Nessuna delle due liste OWASP ha un costo di licenza: sono documenti pubblici, aperti, mantenuti da volontari e sponsor del progetto OWASP. Il costo reale sta negli strumenti e nel tempo necessario per applicarle. Ecco un quadro indicativo dei costi associati a un programma di adozione, utile per un budget italiano o europeo tipico.
| Voce di costo | Solo OWASP Top 10 generale | Solo API Security Top 10 | Entrambe integrate |
|---|---|---|---|
| Licenza documentazione OWASP | Gratuita | Gratuita | Gratuita |
| Scanner SAST/DAST commerciale (tier medio) | Incluso in molte suite generaliste | Spesso modulo separato o add-on | Richiede piano che copra entrambi i ruleset |
| API gateway con policy OWASP-aware | Non necessario | Consigliato, costo variabile per traffico | Necessario per copertura API1-API5 |
| Formazione sviluppatori (giornata) | Corso generico, ampia disponibilità | Corso specialistico, meno disponibile in Italia | Doppio investimento formativo |
| Tempo di audit interno stimato | Settimane, per applicazione monolitica | Giorni per servizio, ma si moltiplica con i microservizi | Somma dei due, con overlap parziale sui controlli comuni |
| Mappatura su compliance UE (NIS2, CRA) | Diretta su A03 e A08 | Indiretta, richiede lavoro di raccordo | Consigliata per organizzazioni regolate |
Il punto chiave sui costi: adottare entrambe le liste non raddoppia la spesa, perché buona parte dei controlli (autenticazione forte, gestione delle configurazioni, logging) serve a coprire categorie di entrambe le liste contemporaneamente. Il costo incrementale reale sta nell’aggiungere un modulo di test specifico per API (rate limiting, BOLA, business flow abuse) sopra a un programma di sicurezza applicativa già esistente.
Strumenti che coprono le due liste: SAST, DAST e API gateway
Sul lato open source, gli strumenti di penetration test come Burp Suite restano il punto di partenza più comune per validare manualmente le categorie della Top 10 generale (injection, XSS, misconfigurazioni), mentre per la sicurezza API servono strumenti che parlino nativamente OpenAPI e GraphQL, capaci di generare richieste con ID di oggetti diversi per testare in automatico gli scenari BOLA. La differenza pratica tra i due mondi di test è che un DAST tradizionale punta un URL e naviga la UI, mentre un tool API-aware ha bisogno dello schema (OpenAPI/Swagger) per capire quali endpoint esistono e quali parametri accettano.
Sul lato SIEM e monitoraggio, piattaforme open source come Wazuh permettono di costruire regole di rilevamento personalizzate sia per gli eventi di accesso anomalo (utili per A01/API1) sia per pattern di traffico che indicano abuso di risorse (API4), a un costo molto più basso rispetto alle piattaforme commerciali enterprise. La scelta tra SIEM open source e commerciale segue in parte la stessa logica della scelta tra le due liste OWASP: dipende da quanto è già maturo il programma di sicurezza interno e da quanta capacità di configurazione ha il team.
Per chi lavora specificamente in Node.js, che resta uno degli stack più diffusi per costruire API REST in Europa, esistono guide pratiche dedicate a implementare singole difese: dal rate limiting (contro API4) all’hashing sicuro delle password con bcrypt (contro API2 e A07), fino alla prevenzione mirata della SQL injection (A05). Nessuno strumento, da solo, copre l’intera lista: la combinazione di test statici, test dinamici e monitoraggio a runtime resta l’approccio più realistico.
Per la sicurezza dell’infrastruttura cloud che ospita queste API, gli strumenti di audit come Prowler e Trivy aiutano a intercettare proprio le misconfigurazioni (A02/API8) prima che diventino sfruttabili: bucket di storage esposti pubblicamente, permessi IAM troppo larghi, immagini container con vulnerabilità note. Sono controlli complementari, non alternativi, a quelli applicativi: una API perfettamente scritta secondo la Top 10 può comunque essere compromessa se il cluster Kubernetes che la ospita ha un dashboard di amministrazione esposto senza autenticazione.
5 casi d’uso reali: quale lista applicare
La scelta tra le due liste, o l’uso combinato, dipende dall’architettura e dal tipo di superficie esposta. Ecco cinque scenari concreti che i team di sviluppo italiani ed europei incontrano più spesso.
- Portale pubblico della PA con form e upload documenti. Qui domina la Top 10 generale. Le categorie A02 (misconfigurazione), A05 (injection) e A09 (logging) coprono la maggior parte dei rischi reali su un’applicazione server-rendered con poche API esposte pubblicamente. Il rischio principale non è quasi mai un endpoint API dimenticato, ma un pannello di amministrazione con credenziali di default o un modulo di upload che non valida correttamente il tipo di file caricato.
- Backend mobile banking con API REST verso l’app. La API Security Top 10 diventa prioritaria. BOLA (API1) e Broken Authentication (API2) sono i rischi con l’impatto potenziale più alto, dato che un errore di autorizzazione può esporre saldi o transazioni di altri clienti. In questo scenario anche API4 (Unrestricted Resource Consumption) merita attenzione, perché un endpoint di trasferimento senza rate limiting può essere abusato per attacchi di frode automatizzata su larga scala.
- Piattaforma e-commerce con checkout e API di terze parti per pagamenti. Servono entrambe le liste. A03/API10 per la fiducia verso fornitori esterni di pagamento, API6 per proteggere il flusso di checkout da abusi automatizzati (bot che generano ordini fittizi per testare carte rubate), A01 per l’accesso agli ordini di altri clienti tramite manipolazione dell’ID ordine nell’URL o nel payload della richiesta.
- Architettura a microservizi con decine di endpoint interni. API9 Improper Inventory Management diventa centrale, perché le versioni deprecate di un’API interna sono spesso il punto debole meno monitorato, insieme ad API4 per il rate limiting tra servizi. Un’API v1 lasciata attiva “per compatibilità” dopo il rilascio della v2, senza gli stessi controlli di autenticazione aggiornati, è uno degli scenari più comuni riscontrati negli audit di ambienti a microservizi maturi.
- SaaS B2B con API pubblica documentata per integratori. Qui la API Security Top 10 guida quasi tutte le decisioni di design, in particolare API3 (esposizione eccessiva di proprietà degli oggetti) e API7 (SSRF), rischi tipici quando terze parti integrano webhook e callback verso URL configurabili dal cliente stesso. Documentare chiaramente lo schema OpenAPI e limitare i campi restituiti per ruolo utente riduce sensibilmente l’esposizione su API3.
Guida alla migrazione: dalla vecchia lista OWASP a quella 2025
Per i team che avevano già mappato controlli sull’edizione 2021 (Top 10 generale) o 2023 (API Security), passare alle versioni 2025 richiede un lavoro di riallineamento, non una riscrittura da zero. Ecco i passaggi pratici.
- Esporta la mappatura attuale dei controlli (regole SAST/DAST, policy WAF, checklist di code review) con i vecchi codici categoria (A01:2021, API1:2023, ecc.).
- Confronta ogni vecchio codice con la tabella di corrispondenza pubblicata da OWASP: alcune categorie sono state rinominate senza cambiare sostanza (es. A07:2021 Identification and Authentication Failures diventa A07:2025 Authentication Failures), altre sono state fuse o scisse.
- Identifica le categorie nuove senza equivalente diretto: A03:2025 Software Supply Chain Failures e A10:2025 Mishandling of Exceptional Conditions per la lista generale, nessuna nuova categoria strutturale per la lista API 2025 rispetto al 2023.
- Aggiorna le regole degli scanner automatizzati (SAST, DAST, API security testing) ai nuovi ruleset: molti vendor commerciali hanno già rilasciato pacchetti aggiornati nel corso del 2026.
- Rivedi la voce SSRF separatamente nei due contesti: se il tuo scanner classificava SSRF come categoria propria, verifica che ora venga correttamente mappata dentro A01 per il codice web generale, mantenendo invece API7 come voce indipendente per il codice API.
- Aggiorna la formazione interna e la documentazione di onboarding degli sviluppatori con i nuovi codici, evitando di lasciare riferimenti misti a versioni 2021/2023 e 2025 nello stesso repository.
- Ripeti un ciclo di penetration test o bug bounty mirato sulle categorie che sono salite di priorità (A02 Security Misconfiguration in primis) per validare che i controlli esistenti coprano davvero il nuovo ordine di rischio.
- Documenta la mappatura verso i requisiti normativi UE rilevanti (NIS2, Cyber Resilience Act), collegando esplicitamente A03 e A08 ai requisiti di trasparenza sulla supply chain software richiesti da ENISA.
Un errore comune durante la migrazione è trattare l’aggiornamento come un semplice “find and replace” dei codici. Le fusioni di categorie (come Excessive Data Exposure e Mass Assignment confluite in API3:2025) cambiano il perimetro di cosa viene effettivamente testato, quindi la revisione va fatta controllo per controllo, non solo etichetta per etichetta.
Un secondo errore, altrettanto comune, è concentrare tutto lo sforzo di migrazione sulla documentazione interna senza toccare le regole effettive degli scanner automatizzati. Un wiki aggiornato con i nuovi codici 2025 non protegge nulla se il ruleset del tool SAST in produzione continua a classificare gli alert con le vecchie categorie del 2021: la coerenza tra documentazione, formazione e configurazione degli strumenti è quello che rende la migrazione realmente efficace, non solo formalmente corretta.
Pro e contro della OWASP Top 10 generale
Pro: copertura ampia su tutto il ciclo di vita applicativo, inclusi aspetti che l’API list non tratta come crittografia e logging. È il riferimento più riconosciuto a livello di compliance e audit, spesso citato direttamente nei requisiti contrattuali. È più semplice da spiegare a un pubblico non tecnico, come management o auditor.
Contro: troppo generica per architetture API-first, dove rischi come BOLA o l’abuso di business flow restano nascosti dentro categorie ampie come “Broken Access Control”. Non copre inventario delle versioni API né il rischio di fiducia eccessiva verso API di terze parti, entrambi problemi frequenti nei microservizi. Un team che si affida solo a questa lista rischia di superare un audit di conformità generico mentre lascia scoperti endpoint API critici, perché nessuna delle sue dieci categorie obbliga esplicitamente a testare l’autorizzazione oggetto per oggetto.
Pro e contro della OWASP API Security Top 10
Pro: granularità molto più alta sui pattern di abuso specifici delle API, con esempi pratici (endpoint, payload, header) direttamente applicabili nei test. Copre scenari come inventario di versioni deprecate e fiducia verso API esterne, del tutto assenti dalla lista generale.
Contro: da sola non copre aspetti trasversali come crittografia, logging strutturato o gestione degli errori, che restano di competenza della Top 10 generale. Meno conosciuta fuori dai team di sviluppo API, il che rende più complesso comunicarla a un board o a un cliente non tecnico. Richiede inoltre che gli sviluppatori abbiano accesso allo schema API (OpenAPI, GraphQL SDL) per essere applicata in modo efficace con strumenti automatizzati, cosa non sempre disponibile in progetti legacy o poco documentati.
Domande frequenti
Devo scegliere una sola delle due liste OWASP?
No. Le due liste coprono rischi parzialmente diversi. Un’organizzazione che espone sia pagine web tradizionali sia API dovrebbe mappare entrambe sullo stesso framework di controllo, evitando di trattarle come alternative. Trattarle come mutuamente esclusive è l’errore di impostazione più comune osservato nei team che affrontano questo confronto per la prima volta.
Qual è la differenza principale tra Broken Access Control (A01) e BOLA (API1)?
Broken Access Control nella Top 10 generale è una categoria ampia che include qualsiasi accesso non autorizzato a risorse, funzioni o dati. BOLA è una sua sottocategoria specifica per le API: si verifica quando un endpoint restituisce o modifica dati di un oggetto (es. un profilo utente) senza verificare che il richiedente abbia i permessi su quello specifico oggetto.
La OWASP Top 10:2025 sostituisce completamente l’edizione 2021?
Sì, secondo la documentazione ufficiale OWASP, l’edizione 2025 è la versione corrente e di riferimento. Qualsiasi documento normativo o contrattuale che cita genericamente “OWASP Top 10” nel 2026 fa implicitamente riferimento all’edizione 2025.
Gli scanner SAST/DAST coprono già i nuovi codici 2025?
Molti vendor hanno aggiornato i ruleset nel corso del 2026 per allinearsi ai nuovi codici categoria, ma è necessario verificare caso per caso con il proprio fornitore, specialmente per la mappatura delle categorie fuse o rinominate.
Perché la Security Misconfiguration è salita così tanto nella Top 10 2025?
L’aumento riflette l’impatto crescente di errori di configurazione in ambienti cloud e containerizzati: policy CORS troppo permissive, credenziali di default lasciate attive, endpoint di debug esposti in produzione. Sono problemi più frequenti oggi che dieci anni fa, quando la Top 10 era dominata da injection e XSS.
Le normative europee come NIS2 citano esplicitamente OWASP?
NIS2 e il Cyber Resilience Act non citano OWASP nominalmente come standard obbligatorio, ma le categorie A03 (Software Supply Chain Failures) e A08 (Software or Data Integrity Failures) si allineano direttamente con i requisiti di trasparenza sulla supply chain software richiesti da ENISA nelle sue linee guida SBOM pubblicate a partire dalla fine del 2025.
Serve un API gateway per applicare la API Security Top 10?
Non è obbligatorio, ma è lo strumento più efficiente per mitigare sistematicamente le prime cinque categorie (API1-API5), secondo lo studio 2025 citato in precedenza. Senza gateway, gli stessi controlli vanno implementati manualmente in ogni singolo servizio, con un rischio più alto di incoerenza.
Quanto tempo serve per completare una migrazione ai codici 2025 su un’applicazione media?
Non esiste un numero universale, perché dipende dalla dimensione della codebase e dal numero di endpoint API esposti. Per un’applicazione monolitica con poche API, il riallineamento della mappatura dei controlli può richiedere alcune settimane; per un’architettura a microservizi con decine di servizi, il lavoro si moltiplica endpoint per endpoint, e i team più organizzati lo trattano come un processo continuo piuttosto che un progetto con una data di fine fissa.
Verdetto: quale lista usare nel 2026
Non c’è un vincitore assoluto, e chi lo presenta come una scelta binaria sta semplificando troppo. I dati raccolti da ENISA su 4.875 incidenti europei confermano che i rischi di accesso e configurazione dominano sia nel mondo web tradizionale sia in quello API, ma con dinamiche diverse abbastanza da giustificare due liste separate.
La raccomandazione pratica: se la tua organizzazione ha ancora una quota significativa di applicazioni web tradizionali (portali, backend server-rendered, form pubblici), la OWASP Top 10:2025 resta il riferimento primario, da integrare con l’API Security Top 10 solo per i servizi che espongono endpoint programmabili. Se invece l’architettura è già API-first o basata su microservizi, la API Security Top 10:2025 dovrebbe guidare la priorità dei test, con la Top 10 generale a coprire gli aspetti trasversali (crittografia, logging, supply chain) che l’API list non tratta.
Per i team con budget limitato, il punto di partenza più efficiente in base ai dati disponibili è: prima Broken Access Control/BOLA (la falla più frequente in entrambe le liste), poi Security Misconfiguration (in forte crescita secondo Qualys), poi Software Supply Chain Failures per allinearsi ai requisiti normativi UE in arrivo con NIS2 e Cyber Resilience Act. Il resto delle categorie si aggiunge man mano che il programma di sicurezza applicativa matura.
Un ultimo consiglio pratico per chi legge da un’azienda italiana con un team di sicurezza piccolo o inesistente: non serve implementare tutte e venti le categorie insieme il primo trimestre. I dati ENISA e le analisi di Qualys e AST Database indicano con chiarezza dove concentrare i primi sei mesi di lavoro, e questo basta per coprire la stragrande maggioranza degli incidenti realmente osservati in Europa nell’ultimo anno.
Related Coverage
- OWASP Top 10 2025 in Node.js: 10 Vulnerabilità, 12 Difese [2026]
- SQL Injection in Node.js: Come Prevenirla in 12 Step [2026]
- Rate Limiting in Node.js: API Sicura in 12 Step [2026]
- Sicurezza Cloud: Audit con Prowler e Trivy, 12 Passi [2026]
- Burp Suite: Test di Sicurezza Web in 12 Step [2026]
- Hashing Password con bcrypt in Node.js: 12 Step [2026]
