Il WAPT, Web Application Penetration Test, è la verifica in cui esperti di sicurezza attaccano un'applicazione web in modo controllato per scoprire le sue vulnerabilità prima che lo faccia qualcun altro. Sembra una cosa da grandi aziende, e invece riguarda chiunque abbia un portale clienti, un e-commerce, una piattaforma SaaS o anche solo un'area riservata sul sito.

Un esempio che rende l'idea. Un'azienda di servizi ha un portale dove i clienti scaricano fatture e contratti. L'indirizzo della pagina finisce con un numero, tipo "documento=1045". Un cliente curioso prova a cambiarlo in 1046 e si ritrova davanti la fattura di un altro cliente. Nessun hacker sofisticato, nessun malware, solo un controllo sugli accessi che mancava. È una delle vulnerabilità più diffuse in assoluto, e uno scanner automatico difficilmente la trova, perché tecnicamente la pagina funziona benissimo.

Il WAPT serve a scovare esattamente questo genere di problemi. E da un paio d'anni ha anche un peso documentale: committenti, bandi pubblici e normative come NIS2 e GDPR chiedono di dimostrare che la sicurezza è stata verificata, e un report di penetration test applicativo è una delle prove più convincenti. Qui trovi come funziona un WAPT, in cosa si distingue da un vulnerability assessment, quali modalità esistono, cosa verifica alla luce della OWASP Top 10:2025 e come si legge il report.

Cos'è un WAPT e cosa si testa in un'applicazione web

Cos'è un WAPT? Un WAPT, o Web Application Penetration Test, è un test di sicurezza in cui analisti specializzati simulano attacchi informatici reali contro un'applicazione web. L'obiettivo è individuare le vulnerabilità, dimostrare se e come possono essere sfruttate e indicare come correggerle, con un report finale che l'azienda può usare sia per intervenire sia come evidenza verso terzi.

Il perimetro di un WAPT è l'applicazione in tutte le sue parti: l'interfaccia che vede l'utente, i servizi di back end, le API, i meccanismi di login e gestione delle sessioni, il controllo di chi può vedere e fare cosa, il dialogo con i database. Le tipologie più comuni sono portali web con aree riservate, API che collegano sistemi diversi, piattaforme SaaS usate da più clienti, servizi online ed e-commerce.

Ognuna ha i suoi punti deboli tipici. Nelle piattaforme SaaS la domanda chiave è se i dati di un cliente restano davvero separati da quelli degli altri. Negli e-commerce si guarda soprattutto a pagamenti, carrelli e account. Nelle API il rischio classico è che un endpoint pensato per uso interno sia raggiungibile dall'esterno, o che restituisca più dati di quanti ne servano. Per le API esiste anche una classifica dedicata dei rischi, la OWASP API Security Top 10, che un buon WAPT tiene in considerazione.

Perché proprio le applicazioni web? Perché sono esposte per definizione. Per attaccare un server interno bisogna prima entrare nella rete, per attaccare un'applicazione web basta un browser. In più sono software vivo: si aggiornano spesso, si integrano con componenti di terze parti, vengono sviluppate con tempi stretti. Ogni rilascio può aprire un varco nuovo.

WAPT, vulnerability assessment e penetration test infrastrutturale: le differenze

Queste tre attività vengono spesso confuse, e la confusione costa cara, perché porta a credersi protetti avendo controllato solo un pezzo del problema.

Il vulnerability assessment identifica e valuta potenziali vulnerabilità, spesso con l'aiuto di scanner automatici: versioni software vecchie, patch mancanti, configurazioni sbagliate. È veloce, ripetibile, economico, ottimo come controllo periodico. Non sempre comprende la verifica controllata della sfruttabilità e dell'impatto delle vulnerabilità. I risultati degli scanner possono inoltre includere falsi positivi, che richiedono una verifica.

Il WAPT approfondisce se e come le vulnerabilità possono essere sfruttate e quale impatto possono avere. Gli analisti usano anche strumenti automatici, ma il grosso del lavoro è manuale: verificano ogni falla, la combinano con altre per costruire scenari di attacco realistici e misurano l'impatto concreto. Le vulnerabilità legate alla logica dell'applicazione, come l'esempio della fattura visto sopra, un carrello che accetta quantità negative o un flusso di pagamento che si può saltare, emergono quasi solo così.

Il penetration test infrastrutturale, infine, guarda a reti, server, firewall, VPN, servizi esposti. È complementare al WAPT: un'infrastruttura blindata può ospitare un'applicazione piena di buchi, e un'applicazione scritta benissimo può stare su un server mal configurato. Chi espone applicazioni critiche di solito affianca le due verifiche.

WAPT black-box, grey-box e white-box: le tre modalità a confronto

Le modalità di un WAPT si distinguono per quante informazioni ricevono gli analisti prima di iniziare. Ognuna simula un attaccante diverso.

Il WAPT black-box: la prospettiva di chi arriva da internet

Nel test black-box gli analisti partono da zero: nessuna credenziale, nessuna documentazione, solo l'indirizzo dell'applicazione. Esattamente come un attaccante qualunque. Mappano la superficie esposta, individuano gli endpoint, cercano le vulnerabilità raggiungibili da fuori. È la modalità che risponde alla domanda più istintiva: cosa vede e cosa può fare chi trova la mia applicazione su internet?

Il WAPT grey-box: cosa succede dopo il login

Nel grey-box gli analisti ricevono le credenziali di uno o più utenti, per esempio un utente standard e un amministratore. Qui si esplora la parte dell'applicazione che sta dietro il login, che è spesso quella dove si nascondono i problemi più gravi. Il focus è il controllo degli accessi. Un utente standard riesce a entrare nelle funzioni da amministratore? Riesce a leggere o modificare i dati di un altro utente? Nel gergo si parla di privilege escalation verticale nel primo caso e orizzontale nel secondo, e sono tra le cause più frequenti di violazioni dei dati.

Il WAPT white-box: il test con tutte le carte in mano

Nel white-box gli analisti hanno accesso completo a codice sorgente, documentazione e architettura. È la modalità più profonda e si avvicina a una revisione del codice orientata alla sicurezza. Richiede più tempo e più coinvolgimento del team di sviluppo. Per la gran parte delle PMI la combinazione di black-box e grey-box dà il miglior equilibrio tra copertura del rischio, tempi e costi, e il white-box si riserva ad applicazioni particolarmente critiche o a fasi specifiche dello sviluppo.

Le fasi di un Web Application Penetration Test

Un WAPT ben fatto segue un percorso in cinque fasi, preceduto da un passaggio preliminare che spesso si sottovaluta.

Il passaggio preliminare è la definizione del perimetro e delle regole di ingaggio. Azienda e analisti concordano quali applicazioni testare, quali ambienti, quali tipologie di utenti, in che finestra temporale, con quali limiti e con quali canali di comunicazione in caso di problemi. Serve anche un'autorizzazione scritta: attaccare un sistema informatico senza il consenso del titolare è un reato, e il documento di autorizzazione tutela entrambe le parti. Se l'applicazione è ospitata da un provider, conviene verificare che le sue condizioni permettano il test.

Poi si parte. La prima fase è la raccolta di informazioni: gli analisti studiano l'applicazione, ne capiscono il funzionamento, mappano architettura, flussi degli utenti, API e tecnologie usate. La seconda è l'identificazione delle vulnerabilità, con strumenti automatici e analisi manuale che si completano. La terza è l'esplorazione approfondita dell'applicazione, dove si mettono sotto pressione autenticazione, sessioni, permessi e gestione degli input. La quarta è l'exploitation, il tentativo controllato di sfruttare le falle individuate per dimostrarne la gravità reale. La quinta è il report, che documenta tutto e indica come intervenire.

Una nota pratica sull'ambiente di test. Quando esiste un ambiente di staging identico alla produzione, è il posto migliore per i test più invasivi. Se si testa in produzione, conviene programmare il lavoro in orari di basso traffico, avere un backup recente e avvisare chi monitora i sistemi, per evitare che il test venga scambiato per un attacco vero.

OWASP Top 10:2025: le vulnerabilità che un WAPT va a cercare

Cos'è la OWASP Top 10? È la classifica dei dieci rischi di sicurezza più critici per le applicazioni web, pubblicata dalla fondazione OWASP. È il riferimento internazionale più usato per classificare le vulnerabilità nei report di penetration test e nei questionari di sicurezza dei fornitori. L'edizione 2025, presentata a novembre 2025 e consolidata a gennaio 2026, è il primo aggiornamento dal 2021.

In cima alla lista resta il controllo degli accessi inefficace, Broken Access Control, che nell'edizione 2025 ingloba anche la Server-Side Request Forgery. È la categoria dell'esempio della fattura: permessi assenti o aggirabili. Al secondo posto sono salite le configurazioni di sicurezza errate, che nel 2021 erano quinte, e il motivo è intuitivo: le applicazioni moderne dipendono sempre di più da configurazioni di cloud, container e servizi esterni.

Al terzo posto c'è una delle due novità, le carenze nella catena di fornitura del software. Estende la vecchia categoria dei componenti vulnerabili e obsoleti fino a includere dipendenze, sistemi di build e infrastrutture di distribuzione. Per chi sviluppa con decine di librerie open source è un tema tutt'altro che teorico.

Seguono gli errori crittografici al quarto posto e le injection al quinto, una famiglia che va dalla SQL injection al cross-site scripting. Al sesto la progettazione insicura, al settimo gli errori di autenticazione, all'ottavo le carenze di integrità del software e dei dati, al nono le carenze di logging e allerta. Chiude la seconda novità dell'edizione 2025, la gestione impropria delle condizioni eccezionali: applicazioni che davanti a un errore imprevisto si comportano in modo insicuro, per esempio mostrando dettagli tecnici o lasciando una transazione a metà.

Perché conta che il report segua questa classificazione? Perché la leggono tutti allo stesso modo: il team di sviluppo, il fornitore esterno, il responsabile sicurezza del cliente, l'auditor. Un report allineato alla OWASP Top 10 entra senza attriti nei processi di qualifica fornitori.

La Top 10 aiuta a classificare i rischi, ma non esaurisce le verifiche di un WAPT: il test deve considerare anche le funzioni e i rischi specifici dell'applicazione.

Quando richiedere un WAPT: i momenti in cui rende di più

Il WAPT dà il massimo quando è legato a momenti precisi della vita di un'applicazione o dell'azienda.

Prima del lancio è il momento ideale. Nessun dato di clienti è ancora esposto, le correzioni si inseriscono nel ciclo di sviluppo e costano molto meno. Dopo ogni modifica importante è il secondo momento chiave, perché una nuova funzionalità o un'integrazione possono aprire una falla che prima mancava. In questi casi il test può concentrarsi sulle parti toccate, con tempi e costi ridotti.

Poi ci sono le occasioni commerciali. Molti bandi pubblici chiedono evidenze di test di sicurezza sulle applicazioni coinvolte nella fornitura, e sempre più clienti privati vogliono un report prima di affidare i propri dati a un fornitore. In entrambi i casi un report WAPT recente, con vulnerabilità descritte per categoria, gravità e stato delle correzioni, è un allegato pronto che fa guadagnare settimane nella qualifica.

Dopo un incidente, la priorità è contenere l'attacco e ricostruire ciò che è successo con attività di incident response e analisi forense. Successivamente, un WAPT mirato può aiutare a verificare le vulnerabilità e le correzioni effettuate.

Quanto spesso ripeterlo? Una buona regola è almeno una volta l'anno sulle applicazioni critiche e comunque dopo ogni rilascio importante. Chi rilascia molto spesso fa bene a integrare test più leggeri nel ciclo di sviluppo e a riservare il WAPT completo alle release principali.

WAPT e compliance: il ruolo del penetration test in NIS2, GDPR e ISO 27001

Il WAPT nasce come attività tecnica, ma oggi ha un ruolo preciso anche nella conformità normativa. Le principali regole su sicurezza e dati chiedono di dimostrare che le misure adottate funzionano, e il penetration test è una delle prove più forti.

Il GDPR, all'articolo 32, chiede a titolari e responsabili del trattamento misure tecniche e organizzative adeguate e, tra queste, una procedura per testare, verificare e valutare regolarmente la loro efficacia. Un WAPT periodico può contribuire alle verifiche previste dall'articolo 32, quando è appropriato rispetto ai rischi del trattamento. Il report documenta i test svolti e va valutato insieme alle misure adottate e alle correzioni effettuate.

La NIS2, recepita in Italia con il D.Lgs. 138/2024, chiede ai soggetti essenziali e importanti misure di gestione del rischio che includono la gestione delle vulnerabilità e la valutazione dell'efficacia delle misure di sicurezza. Per molti soggetti inseriti nell'elenco NIS nel 2025, il termine per adottare le misure di sicurezza di base cade nell'ottobre 2026, secondo il calendario legato alla comunicazione ricevuta da ACN. Un report WAPT, accompagnato dalle correzioni e dal retest, può essere un'evidenza utile per documentare le verifiche svolte.

La ISO 27001:2022 prevede tra i controlli dell'Allegato A la gestione delle vulnerabilità tecniche e i test di sicurezza durante lo sviluppo e l'accettazione dei sistemi. In audit, un report WAPT accompagnato dal piano di correzione e dal retest documenta in modo molto convincente l'efficacia di questi controlli.

Il report WAPT: come è fatto e come usarlo

Il report è il vero prodotto del WAPT: parla a due pubblici diversi e lo fa in due parti.

L'executive summary è per la direzione: livello di rischio complessivo, vulnerabilità più gravi, priorità di intervento, in un linguaggio che si capisce senza essere tecnici. Il capitolo tecnico è per chi deve correggere: per ogni vulnerabilità descrive gli asset coinvolti, la categoria OWASP pertinente e la gravità della vulnerabilità, eventualmente accompagnata da un punteggio CVSS, la dimostrazione della sfruttabilità con i passaggi per riprodurla e le indicazioni operative per risolverla.

Il report però vale quando le falle vengono chiuse. Conviene partire dalle vulnerabilità più gravi e più facili da sfruttare, assegnare un responsabile e una scadenza a ciascuna e tenere traccia dell'avanzamento. Una volta completate le correzioni, il retest verifica che le mitigazioni funzionino e produce un nuovo report. Ai clienti e nelle gare è spesso questo secondo documento il più richiesto, perché dimostra il ciclo completo: problema trovato, problema risolto, soluzione verificata.

Il nostro WAPT: come testiamo le applicazioni delle PMI

Abbiamo pensato il nostro servizio WAPT per le imprese che non hanno un team di sicurezza interno e hanno bisogno di due cose molto concrete: sapere dove mettere le mani e avere un report da mostrare a clienti e committenti.

Mettiamo alla prova portali web, API, piattaforme SaaS, servizi online ed e-commerce, cioè gli applicativi dove una falla si traduce subito in accessi abusivi, dati di clienti esposti, frodi o transazioni compromesse. Lavoriamo in due modalità. Con il black-box guardiamo la tua applicazione con gli occhi di chi arriva da internet senza credenziali e ti diciamo cosa riesce a scoprire. Con il grey-box entriamo con le credenziali di un utente standard e verifichiamo se quel ruolo riesce a spingersi oltre i permessi che dovrebbe avere, individuando i rischi di privilege escalation e indicandoti con precisione dove intervenire.

Il perimetro lo costruiamo con te, in base a quante piattaforme vuoi includere e a quante tipologie di utenti vanno verificate: ogni ruolo, dall'amministratore all'ospite, viene testato separatamente. Il lavoro si svolge tutto da remoto, con la stessa profondità di un test in sede, e un esperto dedicato lo segue dal primo scambio di informazioni fino alla consegna. Ci impegniamo a consegnarti il report in 10-12 giorni lavorativi per applicazione, dalla disponibilità delle informazioni e degli accessi necessari al test.

Quello che ricevi è un report tecnico completo: un executive summary per avere subito il quadro generale e una parte tecnica con asset coinvolti, vulnerabilità associate alle categorie OWASP Top 10, valutazione della loro gravità e indicazioni operative per la correzione. Se vuoi, dopo che hai applicato le correzioni eseguiamo un retest sulle vulnerabilità corrette e ti consegniamo un report che documenta l'esito delle verifiche. E visto che il WAPT è anche un pezzo di NIS2, GDPR e ISO 27001, i nostri Lead Auditor possono agganciare i risultati al tuo percorso di conformità. È una combinazione frequente per le aziende del settore IT e software.

Vuoi sapere quanto è solida la tua applicazione? Scrivici per richiedere il WAPT e definire insieme il perimetro.

Domande frequenti sul WAPT

Cos'è un WAPT in parole semplici?

È un test in cui esperti di sicurezza attaccano la tua applicazione web in modo controllato, con il tuo permesso, per trovare le falle prima di un attaccante vero. Alla fine ricevi un report che spiega cosa hanno trovato, quanto è grave e come sistemarlo. È il modo più diretto per sapere quanto è sicura un'applicazione nel mondo reale.

Che differenza c'è tra WAPT black-box e grey-box?

Nel black-box gli analisti partono senza credenziali e simulano un attaccante esterno. Nel grey-box ricevono le credenziali di uno o più utenti e verificano cosa succede dopo il login, per esempio se un utente riesce a vedere dati di altri o a usare funzioni riservate. Le due modalità si completano, e insieme coprono la gran parte dei rischi di un'applicazione.

Quanto dura un WAPT?

Dipende da quante applicazioni e quanti ruoli utente rientrano nel perimetro e da quanto è complessa l'applicazione. Nel nostro servizio consegniamo il report in 10–12 giorni lavorativi per applicazione, dalla disponibilità delle informazioni e degli accessi necessari al test. Il lavoro si svolge interamente da remoto.

Ogni quanto va fatto un WAPT?

Una buona pratica è almeno una volta l'anno sulle applicazioni importanti e dopo ogni modifica rilevante, come nuove funzionalità, cambi di architettura o nuove integrazioni. Alcuni clienti e bandi chiedono report con una data recente, e vale la pena tenerne conto nella pianificazione.

Il WAPT può mandare in crisi l'applicazione?

Un WAPT professionale segue regole di ingaggio concordate su ambienti, orari e limiti. Gli analisti usano tecniche controllate per dimostrare le vulnerabilità limitando l'impatto sull'operatività. Quando esiste un ambiente di staging identico alla produzione, i test più invasivi si fanno lì. Un backup recente e un avviso a chi monitora i sistemi completano la preparazione.

Il WAPT è obbligatorio per la NIS2?

La NIS2 chiede misure di gestione del rischio che comprendono la gestione delle vulnerabilità e la verifica dell'efficacia delle misure di sicurezza, lasciando all'azienda la scelta degli strumenti. Il WAPT è uno dei modi più efficaci per dimostrarlo sulle applicazioni web esposte, e un report con le remediation è un'evidenza solida in caso di verifica dell'ACN o di richiesta di un cliente.

Cos'è la OWASP Top 10:2025?

È la classifica aggiornata dei dieci rischi più critici per le applicazioni web, pubblicata dalla fondazione OWASP. Al primo posto c'è il controllo degli accessi inefficace, e tra le novità ci sono le carenze nella catena di fornitura del software e la gestione impropria delle condizioni eccezionali. È lo standard più usato per classificare le vulnerabilità nei report di penetration test.

Cosa succede dopo la consegna del report?

Il tuo team di sviluppo, o il fornitore che ha realizzato l'applicazione, corregge le vulnerabilità seguendo priorità e indicazioni del report. Poi puoi chiedere il retest, che verifica le correzioni e produce un nuovo report. Questo secondo documento indica se le vulnerabilità sottoposte a retest risultano risolte ed è spesso quello che clienti e committenti vogliono vedere.