Web application penetration test: cos'è e come funziona

Un web application penetration test (WAPT) è un test di sicurezza offensivo autorizzato il cui perimetro è una singola applicazione web con le sue API: il tester prova a sfruttare autenticazione, autorizzazioni, gestione delle sessioni, validazione degli input e logica di business per dimostrare cosa otterrebbe un attaccante. Si distingue dal penetration test generico perché non esamina la rete, esamina l'applicazione in esecuzione.

La differenza ha conseguenze pratiche su cosa preparare prima di iniziare e su cosa arriva alla fine. Vediamo cosa mette alla prova un WAPT, come si svolge fase per fase, cosa deve contenere il report e cosa incide sui tempi.

Che cos'è un web application penetration test

Il WAPT prende un'applicazione web (il portale clienti, l'area riservata dei fornitori, l'e-commerce, il gestionale esposto su internet) e la mette sotto pressione come farebbe un avversario. Il bersaglio non sono i server su cui gira, sono le funzioni che espone: il form di login, il flusso di reset password, l'endpoint che restituisce l'ordine numero 4172, il campo che accetta un file, il token che tiene aperta la sessione.

Le API rientrano nel perimetro, non sono un'appendice: il front-end è una vetrina, la logica sta dietro chiamate HTTP che un attaccante può invocare direttamente, saltando l'interfaccia. Un test che si ferma a ciò che il browser mostra lascia fuori la parte più interessante.

La cornice generale è quella della guida al penetration test: attività offensiva concordata, delimitata, documentata. Il WAPT ne è la specializzazione applicativa.

WAPT e penetration test generico: cosa cambia davvero

Il perimetro

Un penetration test di rete parte da cosa è raggiungibile: indirizzi, porte, servizi, versioni. Un WAPT parte da cosa fa l'applicazione: quali ruoli esistono, quali dati vede ciascuno, quali passaggi si possono saltare. Un'applicazione può girare su un'infrastruttura aggiornata e restare vulnerabile perché un utente autenticato legge i documenti di un altro cliente cambiando un identificativo nell'URL. Nessuna scansione di rete lo trova: la richiesta è legittima, è il controllo di autorizzazione che manca.

Non è un caso di scuola. Nell'edizione corrente del Top 10 di OWASP, la 2025, il Broken Access Control occupa la prima posizione (A01), seguito da Security Misconfiguration (A02) e Software Supply Chain Failures (A03); Injection è al quinto posto, Authentication Failures al settimo. È un elenco di rischi, non una metodologia di test, ma dice dove conviene guardare.

La metodologia

Il testing di rete si appoggia a quadri generali come PTES, OSSTMM e le linee guida NIST. Per il web esiste un riferimento dedicato: la OWASP Web Security Testing Guide (WSTG), la cui versione stabile 4.2 è pubblicata dal 3 dicembre 2020, con la 5.0 in sviluppo. La WSTG assegna a ogni scenario un identificativo nella forma WSTG-<categoria>-<numero>, così un report può indicare quali verifiche sono state eseguite e quali no. Senza un riferimento condiviso, la profondità del test dipende dalle abitudini di chi lo esegue.

Cosa devi preparare

Un test di rete richiede indirizzi e finestre temporali. Un WAPT richiede anche credenziali di test per ogni ruolo, un ambiente su cui operare e un referente tecnico che sappia dire se una funzione è pensata per fare quello che fa. Sono le richieste che decidono se il test toccherà l'area autenticata o si fermerà sulla soglia.

Cosa viene messo alla prova

La sezione dedicata al testing applicativo della WSTG v4.2 è articolata in dodici aree, che nell'ordine sono:

• raccolta di informazioni sull'applicazione e sulla sua superficie esposta;
• configurazione e deployment, dai file lasciati sul server agli header di sicurezza;
• gestione delle identità, cioè come nascono, cambiano e muoiono gli account;
• autenticazione, dal login al recupero password al secondo fattore;
• autorizzazione, chi può fare cosa e cosa succede se prova a fare altro;
• gestione delle sessioni, token, cookie, scadenze, logout;
• validazione degli input, la famiglia che comprende injection e cross-site scripting;
• gestione degli errori, per capire quanto un messaggio di errore racconta a chi non dovrebbe saperlo;
• crittografia debole, dal trasporto agli archivi;
• logica di business, l'area che nessuno scanner copre;
• test lato client, quello che accade nel browser dell'utente;
• API testing, aggiunto nella 4.2.

La decima voce merita una nota. I difetti di logica di business non sono errori di codice: sono passaggi che l'applicazione consente e che non dovrebbe. Applicare un buono sconto due volte, confermare un ordine senza che il pagamento sia andato a buon fine, approvare la propria richiesta di autorizzazione. Nessuno strumento automatico li rileva, perché tecnicamente l'applicazione funziona: li trova una persona che ha capito il processo. Sono anche i difetti con l'impatto più diretto sul conto economico.

Come si svolge, fase per fase

Lo schema di riferimento è quello del NIST SP 800-115, la Technical Guide to Information Security Testing and Assessment pubblicata nel settembre 2008, che descrive quattro fasi del penetration testing: planning, discovery, attack e reporting. Un dettaglio del documento vale più di molte spiegazioni: il reporting non è l'ultima fase in fila, si svolge in parallelo alle altre tre. Il piano di test nasce nella pianificazione, i log si scrivono durante discovery e attack.

1. Pianificazione. Perimetro (quali domini, API e ruoli), obiettivi, regole d'ingaggio, autorizzazione formale, finestre operative, canale di allerta immediata se emerge qualcosa di grave. Nel SP 800-115 in questa fase non si esegue alcun test.
2. Discovery. Mappatura dell'applicazione (percorsi, parametri, endpoint, tecnologie, ruoli) e analisi delle vulnerabilità, che confronta quanto trovato con le debolezze note e con le aree della WSTG.
3. Attack. Ogni ipotesi viene provata: è qui che il potenziale diventa dimostrato e il test si separa da una scansione. Il SP 800-115 prevede un ritorno alla discovery quando lo sfruttamento apre nuove strade, per esempio credenziali recuperate che rendono visibile un'area prima inaccessibile. Si valuta anche fin dove si arriva: escalation dei privilegi, accesso ai dati di altri utenti, uscita verso il sistema sottostante.
4. Reporting e retest. Il documento finale e la verifica delle correzioni.

Black box, grey box o white box

Sul web la scelta è meno aperta di quanto sembri. Il black box senza credenziali riproduce l'attaccante anonimo, ma esclude tutto ciò che sta dietro il login, cioè quasi tutta l'applicazione. Il grey box con un account per ciascun ruolo è la configurazione che rende visibili i difetti di autorizzazione: si scoprono solo confrontando cosa vede un ruolo e cosa riesce a vedere quando prova a chiedere di più. Il white box, con accesso al codice, dà la copertura maggiore e ha senso quando l'applicazione è sviluppata in casa.

Se il confine con la verifica in ampiezza non è chiaro, il confronto tra penetration test e vulnerability assessment lo mette in fila, e la scheda su cos'è un vulnerability assessment spiega cosa copre la scansione periodica.

Cosa consegna un WAPT

Il valore del test si vede dal report. Un deliverable utile contiene:

• una sintesi per chi decide, in cui il rischio è espresso in termini di dati e processi, non di CVE;
• l'elenco dei findings con severità e con il contesto che la giustifica, perché la stessa vulnerabilità pesa in modo diverso su un blog e su un portale che espone dati di clienti;
• per ogni finding la catena riproducibile: richiesta, parametro, risposta, prova. Se lo sviluppatore non può riprodurre il problema, la correzione diventa un'ipotesi;
• la remediation prioritizzata, con indicazioni tecniche e non "sanitizzare gli input";
• un retest concordato, per verificare che le correzioni tengano e non ne abbiano introdotte altre.

Se il test serve anche a dimostrare qualcosa a un cliente o a un auditor, conviene concordare in anticipo il criterio di verifica. L'OWASP Application Security Verification Standard (ASVS), alla versione 5.0.0 rilasciata il 30 maggio 2025, offre requisiti verificabili a cui il report può agganciarsi: l'esito diventa "questi requisiti sono soddisfatti, questi no" invece di un giudizio complessivo.

Quando serve

Quattro momenti in cui un WAPT ripaga l'impegno.

Prima del go-live. Una nuova applicazione o un rifacimento importante vanno testati quando c'è ancora margine per correggere l'architettura.

Dopo un cambiamento rilevante. Nuovo provider di autenticazione, nuova area riservata, API aperte a un partner: la superficie cambia e il test precedente non copre il pezzo nuovo.

Quando lo chiede un cliente o una gara. Nel mid-market è la richiesta più frequente: un cliente strutturato vuole l'esito di un test applicativo recente come condizione per firmare. Qui il report è anche un documento commerciale, e la sua leggibilità conta.

Per gli adempimenti. Nessuna norma nomina l'acronimo WAPT, ma diversi quadri ci arrivano per sostanza. L'Allegato A della ISO/IEC 27001:2022 prevede la gestione delle vulnerabilità tecniche (controllo 8.8) e i test di sicurezza in fase di sviluppo e accettazione (8.29): il quadro è nella guida alla ISO 27001. La NIS2, recepita con il D.Lgs. 138/2024, include tra le misure minime dell'art. 24 la sicurezza dell'acquisizione, dello sviluppo e della manutenzione dei sistemi informativi e di rete, compresa la gestione delle vulnerabilità, e politiche per valutare l'efficacia delle misure adottate: vedi la guida alla NIS2. Per il comparto finanziario, DORA colloca il penetration test nel programma di test di base, con il TLPT riservato alle entità significative (test di resilienza DORA).

Cosa incide su tempi e impegno

Due applicazioni che sembrano simili possono richiedere un impegno molto diverso. I fattori che pesano:

• numero di ruoli e di funzioni: ogni ruolo aggiuntivo moltiplica le combinazioni di autorizzazione da verificare;
• ampiezza delle API: quanti endpoint, con quale documentazione disponibile;
• complessità dell'autenticazione: single sign-on, secondo fattore, federazione con identità esterne;
• ambiente di test: uno staging fedele alla produzione semplifica tutto, un test in produzione richiede cautele e finestre concordate;
• presenza di un WAF: se resta attivo il test misura anche il filtro, se si concorda un bypass misura l'applicazione. Va deciso prima;
• retest incluso o separato, e con quale finestra temporale.

Questi elementi vanno fissati nello scoping. Un preventivo che non li nomina sta stimando alla cieca.

Tre errori che svuotano il test

• Testare senza credenziali per risparmiare tempo. Si ottiene un test della pagina di login: l'area dove stanno i dati resta inesplorata.
• Chiudere il progetto con la consegna del PDF. Senza retest nessuno sa se le correzioni hanno funzionato.
• Trattarlo come un evento annuale isolato. Un WAPT fotografa un momento, ma l'applicazione cambia a ogni rilascio: è il problema che il penetration test as a service affronta distribuendo i test nel tempo.

Dal report alla postura reale

Un test applicativo dice cosa è sfruttabile oggi, non se qualcuno ci sta provando adesso: per quello servono i log dell'applicazione e del suo contorno, raccolti e correlati, che è il lavoro di un SIEM dentro un presidio operativo. Il test riduce la superficie sfruttabile, il monitoraggio continuo riduce il tempo in cui un tentativo passa inosservato. AmagisTech lavora con il mid-market italiano su entrambi i fronti: se hai un'applicazione da mettere alla prova e vuoi definire perimetro, ruoli e tempi, parliamone in una call di scoping.