Burp Suite e OWASP ZAP sono due proxy di intercettazione per analizzare, modificare e automatizzare le richieste HTTP di una web app durante un security assessment. Burp Suite punta su un'esperienza operativa molto rifinita e su workflow rapidi per il testing manuale, mentre OWASP ZAP offre una piattaforma open source con scanner integrato, API e automazione accessibili senza costi di licenza.

La scelta non si riduce a quale scanner trova più vulnerabilità. In un assessment reale contano la qualità del proxy, la velocità con cui si ripete una richiesta, la gestione dell'autenticazione, il controllo sullo scope e il tempo necessario per verificare i falsi positivi. Uno scanner che produce molti risultati non validati può rallentare il lavoro più di quanto lo acceleri.

Questo articolo confronta i due strumenti usando la stessa sequenza operativa:

  1. configurazione del proxy e del browser;
  2. crawling e raccolta degli endpoint;
  3. analisi delle richieste autenticate;
  4. modifica e replay con Repeater o Request Editor;
  5. scansione passiva e attiva;
  6. automazione, estensioni e gestione dei risultati.

Le prove vanno eseguite su applicazioni proprie o su ambienti esplicitamente autorizzati. Per un laboratorio riproducibile si possono usare OWASP Juice Shop, WebGoat o PortSwigger Web Security Academy.

Indice

Differenze principali

Entrambi gli strumenti si posizionano tra browser e applicazione. Il browser invia una richiesta al proxy locale, il proxy la visualizza e può inoltrarla al server dopo averla modificata. La stessa richiesta può poi essere salvata, ripetuta e trasformata in un caso di test.

Area Burp Suite OWASP ZAP
Proxy Proxy stabile, interfaccia molto curata e ottimi strumenti per il controllo del traffico Proxy completo, integrato con HUD e contesti di scansione
Replay manuale Repeater rapido e adatto a test iterativi Request Editor e resend disponibili, con workflow meno focalizzato sul replay
Scanner Passive Scanner nelle versioni gratuite; scansione attiva nelle edizioni a pagamento Passive e Active Scanner inclusi nella piattaforma
Automazione API, headless scanner e integrazioni soprattutto nelle edizioni professionali API, Automation Framework e integrazione con pipeline CI/CD
Estensioni BApp Store e API Montoya per estensioni Java Marketplace, add-on e API Java, Python e script
Gestione risultati Issue definitions e organizzazione efficace nei progetti Alert, Risk, Confidence e filtri configurabili
Licenza Community gratuita con limitazioni operative; Professional e Enterprise a pagamento Open source e gratuito, con supporto commerciale opzionale

Burp Suite tende a essere più veloce nelle attività manuali. ZAP offre una superficie di automazione più facile da adottare in un progetto che deve essere eseguito da script o pipeline. Questa distinzione pesa più del confronto astratto tra i due scanner.

Burp Suite: workflow operativo

Configurare il proxy

Dopo l'avvio di Burp Suite, il proxy viene esposto normalmente su 127.0.0.1:8080. Si può usare il browser integrato di Burp oppure configurare manualmente Firefox o Chromium.

La configurazione manuale richiede anche l'installazione del certificato CA generato da Burp, necessario per ispezionare il traffico HTTPS senza errori di certificato nel browser. Il certificato va installato solo nell'ambiente di test e non in un profilo usato per la navigazione quotidiana.

Nel pannello Proxy > Intercept, l'intercettazione può essere attivata o disattivata. Durante la fase esplorativa conviene lasciarla disattivata e osservare il traffico in HTTP history. L'intercettazione continua di ogni richiesta rende il browsing lento e aggiunge rumore.

La funzione Proxy > Settings permette di configurare scope, regole di intercettazione e gestione delle richieste WebSocket. Limitare subito lo scope al dominio dell'applicazione evita di registrare traffico esterno come analytics, CDN o servizi di terze parti.

Raccogliere endpoint e superficie applicativa

Il browser viene usato per percorrere manualmente le funzioni principali dell'applicazione: login, ricerca, modifica del profilo, upload, API e logout. Ogni richiesta osservata compare nella cronologia e può essere aggiunta al site map.

La navigazione manuale resta utile anche se si dispone di uno scanner automatico. Le applicazioni moderne costruite con JavaScript possono caricare endpoint solo dopo un'interazione, mentre un crawler generico può non raggiungere menu, modali o flussi protetti da stato client-side.

Per includere una richiesta nel test basta controllare host, porta e protocollo nella cronologia. Da qui si possono inviare gli elementi selezionati a Repeater, Intruder o Organizer. Le estensioni installate dal BApp Store possono aggiungere analisi per JWT, GraphQL, OpenAPI e altri formati.

Analizzare l'autenticazione

Burp conserva cookie, header e token osservati durante la navigazione. Una richiesta autenticata può essere inviata a Repeater per verificare il comportamento con un altro utente, con un token scaduto o senza un parametro di autorizzazione.

Il controllo deve distinguere autenticazione e autorizzazione. Rimuovere il cookie e verificare un redirect al login testa la prima. Sostituire l'identificativo di una risorsa con quello appartenente a un altro account serve invece a verificare l'access control.

Per i flussi complessi, Burp Professional offre funzionalità di session handling che possono aggiornare token e cookie prima dell'invio. La configurazione richiede attenzione: un macro registrato male può rinnovare la sessione sbagliata o produrre risultati apparentemente validi ma non riproducibili.

Ripetere e modificare le richieste

Il passaggio da HTTP history a Repeater è uno dei punti forti di Burp. La richiesta resta disponibile in una scheda dedicata, dove si possono modificare metodo, path, query string, header e body. L'invio mostra status code, dimensione, tempi e risposta completa.

Un test semplice su un endpoint JSON può partire da una richiesta come questa:

POST /api/profile HTTP/1.1
Host: app.test
Content-Type: application/json
Authorization: Bearer <token>

{"displayName":"Alice"}

In Repeater si può cambiare il campo, rimuovere l'header Authorization, aggiungere parametri inattesi o alterare il metodo HTTP. Il confronto tra risposte può essere aiutato dalla funzione di comparazione, utile quando il server restituisce pagine quasi identiche con una sola differenza significativa.

Intruder è adatto a test parametrizzati su un singolo punto della richiesta. La Community Edition limita la velocità degli attacchi, mentre le edizioni a pagamento rimuovono questo vincolo. Per molte verifiche manuali, comunque, Repeater resta più controllabile e produce meno rumore.

Eseguire lo scanning

Burp Passive Scanner analizza il traffico osservato senza inviare richieste aggiuntive. Può segnalare cookie privi di attributi, header mancanti, mixed content e altri problemi rilevabili dalla risposta.

La scansione attiva è disponibile nelle edizioni professionali. Prima di avviarla occorre definire lo scope, escludere endpoint distruttivi e considerare il comportamento delle funzionalità che modificano dati. L'uso indiscriminato di active scan su un ambiente condiviso è una pratica sbagliata, indipendentemente dalla qualità del tool.

I risultati includono una descrizione, una richiesta di esempio, una risposta e indicazioni sulla confidenza. Un finding va validato con Repeater: il report dello scanner è un punto di partenza, non la prova conclusiva della vulnerabilità.

OWASP ZAP: workflow operativo

Configurare il proxy

ZAP usa anch'esso, per impostazione comune, 127.0.0.1:8080. Il browser può essere avviato direttamente dall'interfaccia di ZAP, oppure configurato per usare il proxy e il certificato CA locale.

L'interfaccia mostra il traffico nei nodi del Sites tree. Il pannello History permette di filtrare richieste e risposte, mentre il tab HUD può sovrapporre controlli e informazioni direttamente alla pagina del browser. HUD è utile per chi vuole vedere rapidamente lo stato della sessione, ma può risultare ingombrante durante un'analisi dettagliata.

ZAP organizza il lavoro attraverso i Context. Un context raccoglie URL, autenticazione, utenti e regole di inclusione o esclusione. Definirlo all'inizio aiuta lo scanner a distinguere l'applicazione target da risorse esterne.

Raccogliere endpoint e superficie applicativa

La navigazione manuale popola il Sites tree con pagine, API, parametri e risposte. ZAP può anche usare lo spider tradizionale o l'AJAX Spider per seguire applicazioni con una componente JavaScript più complessa.

Lo spider tradizionale lavora bene con link HTML e percorsi prevedibili. L'AJAX Spider utilizza un browser per eseguire JavaScript e raggiungere elementi generati dal client, ma può richiedere più tempo e dipendenze locali.

Quando l'applicazione espone una specifica OpenAPI, questa può essere importata per creare una superficie di test più completa. È una soluzione preferibile alla scoperta casuale degli endpoint: il documento descrive metodi, parametri e schemi che il crawler potrebbe non incontrare.

Gestire login e utenti

ZAP supporta sessioni, context e utenti definiti per lo scanning. Il pannello Session Properties consente di impostare il metodo di gestione della sessione, mentre le proprietà del context possono includere login URL e dati necessari all'autenticazione.

Un assessment con due utenti richiede una configurazione esplicita. Le richieste devono essere associate all'utente corretto e l'applicazione deve essere monitorata per verificare che il token venga rinnovato senza interrompere la scansione.

La configurazione automatica del login non è sempre sufficiente per applicazioni con MFA, CAPTCHA o challenge dinamiche. In queste situazioni è spesso più affidabile effettuare il login nel browser, verificare che ZAP abbia catturato la sessione e poi usare le richieste registrate come base per i test manuali.

Modificare e ripetere le richieste

Una richiesta del pannello History può essere aperta con Open/Resend with Request Editor. L'editor permette di cambiare il messaggio HTTP e inviarlo nuovamente, visualizzando risposta, status code e header.

Riprendendo l'esempio precedente, il test può essere eseguito così:

POST /api/profile HTTP/1.1
Host: app.test
Content-Type: application/json
Authorization: Bearer <token>

{"displayName":"Alice"}

Si modifica il body, si elimina il token oppure si sostituisce il valore di un identificativo. ZAP consente anche di aggiungere la richiesta a una sessione di confronto e di usare script per trasformare automaticamente messaggi prima dell'invio.

Rispetto a Repeater, Request Editor richiede qualche passaggio in più per un ciclo molto rapido di modifica e invio. In compenso l'integrazione con gli script apre possibilità interessanti per chi vuole costruire controlli ripetibili.

Eseguire lo scanning

ZAP include Passive Scanner e Active Scanner. Il primo analizza il traffico già osservato, mentre il secondo invia payload aggiuntivi agli endpoint selezionati.

Lo Scan Policy Manager permette di scegliere quali plugin attivare e con quale livello di aggressività. La regolazione è importante: uno scan completo può generare un numero elevato di richieste e alert, soprattutto su API con molti parametri.

Un esempio di avvio da riga di comando con Docker è:

docker run --rm -t \
  -v "$PWD/reports:/zap/wrk:rw" \
  ghcr.io/zaproxy/zaproxy:stable \
  zap-baseline.py \
  -t https://app.test \
  -r baseline.html

zap-baseline.py esegue una scansione passiva e una navigazione limitata, producendo un report. Non sostituisce un active scan né la validazione manuale. In una pipeline CI il livello di severità che causa il fallimento del job va deciso in base alle regole del progetto, non accettato come impostazione implicita.

Confronto tra scanner e falsi positivi

Gli scanner lavorano per euristiche. Un cookie senza HttpOnly può essere intenzionale per una sessione gestita da JavaScript, mentre un header assente può essere irrilevante se il contesto non lo richiede. Il risultato automatico va sempre collegato a un impatto concreto.

Risultato Verifica manuale
Cookie senza Secure controllare se il cookie viene trasmesso su HTTPS e se esistono percorsi HTTP raggiungibili
Missing security header verificare il comportamento effettivo del browser e il tipo di contenuto servito
Reflected input controllare il contesto di output e la possibilità di eseguire codice
Access control sospetto ripetere la richiesta con un secondo utente e confrontare status, body e side effect
CORS permissivo testare origin, credenziali e dati realmente restituiti
SQL error o anomalie di risposta riprodurre il comportamento con input controllati e valutare l'eventuale accesso ai dati

Burp presenta spesso i risultati con un flusso più orientato alla triage manuale e alla produzione del report. ZAP distingue tipicamente Risk e Confidence, una separazione utile per non trattare un alert a bassa confidenza come una vulnerabilità confermata.

In entrambi i casi conviene registrare quattro elementi: richiesta originale, modifica applicata, risposta osservata e impatto. Un finding senza questa traccia è difficile da verificare e ancora più difficile da correggere.

Automazione ed estensioni

ZAP ha un vantaggio netto nell'automazione accessibile. L'API può essere usata per avviare spider, scanner e raccolta dei risultati. L'Automation Framework consente di descrivere il piano di lavoro in un file YAML, rendendo il comportamento più riproducibile tra ambienti.

Burp offre automazione tramite API e strumenti headless soprattutto nelle edizioni professionali. Le estensioni del BApp Store ampliano il prodotto con funzioni per JWT, autorizzazione, logging, GraphQL e analisi personalizzate. L'ecosistema è molto pratico, ma la disponibilità di alcune funzioni dipende dalla licenza.

Per estensioni personalizzate, Burp usa oggi l'API Montoya, mentre ZAP supporta add-on e script in diversi linguaggi. Un'estensione dovrebbe aggiungere un controllo specifico o ridurre lavoro ripetitivo. Installare molti add-on senza valutarne manutenzione e permessi rende l'ambiente meno prevedibile.

Un caso concreto è il test di autorizzazione su più oggetti. Uno script può estrarre un identificativo dalla risposta, sostituirlo nella richiesta successiva e confrontare il risultato con quello ottenuto dall'utente autorizzato. Questo tipo di controllo richiede una logica applicativa che uno scanner generalista non può dedurre in modo affidabile.

Costi e scelta dello strumento

OWASP ZAP è open source e può essere usato senza acquistare una licenza. Questo lo rende adatto a laboratori, progetti didattici, team che costruiscono pipeline interne e assessment in cui il budget per i tool è limitato.

Burp Suite Community Edition è sufficiente per proxy, cronologia e una parte consistente del testing manuale. Le limitazioni più rilevanti riguardano velocità e disponibilità delle funzioni avanzate, tra cui active scanning e alcune capacità di automazione. Burp Suite Professional aggiunge lo scanner, Intruder senza il limite di velocità della Community Edition, funzioni di progetto e integrazioni dedicate.

I prezzi e i modelli commerciali possono cambiare, quindi la valutazione economica va fatta sulla pagina ufficiale del prodotto e sulla licenza applicabile al team. Il costo della licenza va confrontato con il tempo risparmiato nel replay, nella triage e nella reportistica, non solo con il numero di feature elencate.

La scelta pratica può seguire questo criterio:

  • Burp Suite per assessment manuali intensivi, debugging rapido delle richieste e workflow individuali molto frequenti;
  • OWASP ZAP per automazione, integrazione CI/CD e attività che devono restare interamente open source;
  • entrambi per validazioni incrociate, quando il progetto richiede sia un flusso manuale veloce sia una scansione automatizzata indipendente.

Workflow consigliato

Un processo efficace può iniziare con ZAP in una pipeline di baseline, così da intercettare regressioni su header, cookie e configurazioni evidenti a ogni modifica dell'applicazione. I risultati con severità significativa vanno filtrati e inviati al team solo dopo una verifica minima.

L'analisi manuale può poi passare a Burp Suite, soprattutto per testare autorizzazione, manipolazione dei parametri, business logic e flussi che dipendono da più richieste. Repeater e la cronologia rendono semplice costruire una serie di casi controllati.

L'uso combinato non deve diventare duplicazione meccanica. Eseguire lo stesso active scan con configurazioni identiche su due strumenti raramente raddoppia la copertura. Ha più valore usare il secondo tool per controllare endpoint diversi, riprodurre un finding o verificare un risultato incerto con una tecnica differente.

La sequenza ripetibile resta questa: definire lo scope, registrare il flusso autenticato, raccogliere gli endpoint, ripetere manualmente le richieste sensibili, avviare passive scan, eseguire active scan su un ambiente controllato e validare ogni alert. Il report finale dovrebbe separare vulnerabilità confermate, osservazioni informative e falsi positivi chiusi.

Risorse