OWASP ZAP 2.17: Testa la Sicurezza API in 5 Step [2026]

Chi si occupa di sicurezza applicativa lo sa: prima o poi arriva il momento in cui bisogna dimostrare che un’API o un’applicazione web reggono a un attacco reale, non solo a una checklist teorica. OWASP ZAP (Zed Attack Proxy) resta uno degli strumenti open source più usati per questo lavoro, ed è arrivato alla versione 2.17.0, rilasciata a dicembre 2025 e ancora indicata come release stabile di riferimento sulla pagina ufficiale dei download. In questa guida vediamo, passo dopo passo, come installarlo, configurarlo e usarlo per testare sia applicazioni web sia API REST, fino a integrarlo in una pipeline CI/CD su GitHub Actions.

Il contesto aiuta a capire perché vale la pena investire tempo in questo tipo di test. Secondo le previsioni di metà 2026 pubblicate da FIRST.org, il numero totale di CVE registrate nell’anno dovrebbe avvicinarsi a 66.000, un volume che rende impossibile affidarsi solo a controlli manuali. Sul fronte delle piccole e medie imprese, i dati citati da Verizon nel report 2025/2026 indicano che l’88% delle violazioni subite da PMI ha coinvolto ransomware, mentre la ricerca Sophos 2026 sul ransomware segnala che solo il 34% delle organizzazioni di piccole dimensioni è riuscito a fermare un attacco prima della cifratura o dell’estorsione dei dati. Anche l’ultimo ENISA Threat Landscape conferma che le applicazioni web e le API restano tra i vettori di attacco più sfruttati in Europa. Testare le proprie applicazioni prima che lo facciano altri, insomma, non è più un esercizio accademico.

Questa guida è pensata per chi già sviluppa o gestisce API e applicazioni web e vuole introdurre un controllo di sicurezza ripetibile senza dover acquistare licenze commerciali. Copriremo l’installazione, la configurazione del proxy, la scansione autenticata, l’automazione via YAML e infine l’integrazione in una pipeline CI/CD reale, con esempi di codice pronti da adattare al proprio progetto. Alla fine troverete anche una sezione dedicata agli errori più comuni, una lista di problemi tecnici frequenti con relativa soluzione e un progetto completo che mette insieme tutti i pezzi.

Cos’è OWASP ZAP e perché sceglierlo nel 2026

OWASP ZAP è un proxy di intercettazione pensato per il security testing di applicazioni web e API. Nasce come progetto della fondazione OWASP e oggi è mantenuto sotto l’egida di Checkmarx, che ne cura le release e il marketplace degli add-on. A differenza di un semplice scanner “punta e clicca”, ZAP funziona come un vero proxy: si mette in mezzo tra il browser (o il client API) e il server, osserva ogni richiesta e risposta, e da lì può passivamente analizzare il traffico oppure lanciare test attivi che inviano payload di attacco controllati.

La differenza pratica rispetto ad altri strumenti di penetration test sta soprattutto nel modello di licenza: ZAP è completamente gratuito e open source, incluse le funzionalità di scansione attiva e l’Automation Framework, che in prodotti commerciali sono spesso riservate alle versioni a pagamento. Questo lo rende la scelta naturale per team con budget limitato, per progetti didattici e per pipeline CI/CD dove non ha senso pagare licenze per ogni singola esecuzione automatica.

Un punto da tenere presente riguarda gli aggiornamenti di sicurezza dello strumento stesso: il blog ufficiale di ZAP ha invitato più volte gli utenti ad allinearsi alla linea 2.17.x, segnalando che alcune versioni precedenti e alcuni add-on più vecchi presentavano problemi di sicurezza, incluso un rischio di esecuzione di codice da remoto in scenari specifici. Usare uno strumento di sicurezza vulnerabile per testare la sicurezza altrui è un controsenso che vale la pena evitare fin dal primo passo. Lo storico completo delle versioni, con le relative note di rilascio, è consultabile sulla pagina release ufficiale su GitHub.

Un breve inquadramento del progetto

ZAP ha una storia particolare rispetto alla maggior parte degli strumenti di sicurezza: è nato come progetto comunitario sotto l’ombrello OWASP e ha mantenuto per anni un modello di governance aperta, con contributi da centinaia di sviluppatori indipendenti. Il passaggio del coordinamento tecnico a Checkmarx non ha cambiato la licenza né il modello di distribuzione gratuita, ma ha portato un ritmo di rilascio più regolare e una manutenzione più prevedibile degli add-on principali, un aspetto che pesa parecchio quando lo strumento deve girare ogni notte dentro una pipeline aziendale.

Scansione passiva e scansione attiva: la differenza che conta

Prima di lanciare qualsiasi comando, vale la pena chiarire un concetto che genera confusione fin dai primi utilizzi. La scansione passiva osserva soltanto il traffico che passa attraverso il proxy: legge header, cookie e contenuto delle risposte alla ricerca di configurazioni deboli, senza mai inviare dati non previsti dall’applicazione. È per definizione sicura da eseguire ovunque, anche in produzione. La scansione attiva, al contrario, inietta payload pensati per far emergere vulnerabilità come SQL injection o cross-site scripting: modifica lo stato dell’applicazione, può scrivere dati di test in un database e va quindi trattata come un vero attacco simulato, da eseguire solo su ambienti autorizzati e isolati.

Prerequisiti: versioni, hardware e permessi

Prima di installare qualsiasi cosa, serve mettere in chiaro tre elementi: l’ambiente tecnico, le risorse hardware e, soprattutto, l’autorizzazione a testare il bersaglio. Nessuno strumento, per quanto legale sia possederlo, autorizza a scansionare un sito o un’API di terzi senza consenso esplicito: farlo può configurare un accesso abusivo a sistema informatico. La tabella seguente riassume i requisiti minimi consigliati per un uso professionale di ZAP 2.17.0.

Componente	Versione o requisito minimo	Note
OWASP ZAP	2.17.0 o successiva	Scaricare solo dal sito ufficiale zaproxy.org
Java Runtime	Incluso nel pacchetto ZAP (Zulu JRE)	Non serve installare Java separatamente per i pacchetti desktop
Docker	Versione recente stabile	Necessario per l’immagine ufficiale ghcr.io/zaproxy/zaproxy
RAM	Minimo 4 GB, consigliati 8 GB	Le scansioni attive su siti grandi consumano molta memoria
Sistema operativo	Windows 10/11, macOS, Linux	Pacchetti nativi disponibili per tutte e tre le piattaforme
Browser	Firefox o Chrome aggiornati	Serve per l’estensione proxy durante i test manuali

Oltre all’hardware, serve un ambiente di test: non lanciate mai una scansione attiva contro un sistema di produzione senza una finestra di manutenzione concordata. Il modo più sicuro per imparare è allestire un ambiente di staging isolato o usare applicazioni volutamente vulnerabili pensate per l’addestramento. Prima di procedere, mettete per iscritto (anche solo in un’email interna) chi ha autorizzato il test, su quale ambiente e in quale finestra temporale: è la prassi minima che qualsiasi responsabile di sicurezza richiederebbe, ed è la prima cosa che verrà chiesta in caso di effetti collaterali imprevisti su un servizio condiviso.

Il Marketplace degli add-on: cosa installare subito

Appena avviato, ZAP include già lo Spider, la scansione passiva e attiva di base e i report HTML/XML/JSON. Ma la parte più utile per un uso professionale arriva dal Marketplace degli add-on, accessibile dall’icona a forma di puzzle nella barra degli strumenti. Prima di iniziare a testare API reali conviene installare almeno cinque componenti: Automation Framework (per gli scan riproducibili via YAML, descritti più avanti), OpenAPI Support (per importare schemi Swagger/OpenAPI), GraphQL Support (per le API basate su query GraphQL), Authentication Helper (che semplifica la configurazione del login rispetto agli script manuali) e Alert Filters (per gestire i falsi positivi senza modificare la policy di scansione globale).

La documentazione ufficiale di ciascun add-on, incluse le note di compatibilità con la versione 2.17.0, si trova nella sezione Docs del sito ufficiale. Vale la pena controllarla periodicamente: gli add-on si aggiornano con un ritmo indipendente dal core di ZAP, e una versione disallineata può causare errori poco chiari durante l’esecuzione di un job dell’Automation Framework.

Passo 1-2: scaricare e installare OWASP ZAP 2.17.0

Il primo passo è scaricare il pacchetto corretto per il proprio sistema operativo dalla pagina ufficiale dei download. Su Windows e macOS è disponibile un installer grafico che include già il runtime Java necessario, quindi non serve configurare nulla a parte l’installazione stessa. Su Linux, invece, molti preferiscono l’immagine Docker ufficiale, che evita conflitti con versioni di Java già presenti sul sistema ed è la scelta più comoda anche per l’uso in pipeline automatizzate.

Per avviare ZAP in modalità daemon (senza interfaccia grafica, utile per l’automazione) via Docker, il comando è il seguente:

docker run -u zap -p 8080:8080 -i ghcr.io/zaproxy/zaproxy:stable zap.sh -daemon \
  -host 0.0.0.0 -port 8080 \
  -config api.addrs.addr.name=.* \
  -config api.addrs.addr.regex=true \
  -config api.key=LA_TUA_API_KEY

Se invece preferite l’installazione desktop, dopo il primo avvio ZAP chiede se creare una sessione persistente o usare una sessione usa e getta: per test ripetuti su un progetto reale conviene sempre salvare la sessione, così da poter confrontare i risultati di scansioni successive. Prima di eseguire l’installer, è buona norma verificare il checksum del file scaricato rispetto a quello pubblicato sulla pagina ufficiale dei download: un file manomesso è un vettore di attacco ben noto per chi distribuisce falsi strumenti di sicurezza.

Passo 3-4: configurare il proxy e il browser

Per intercettare il traffico HTTPS in modo pulito, ZAP genera un certificato root che va importato nel browser di test. Dal menu Strumenti > Opzioni > Dynamic SSL Certificate si esporta il certificato in formato .cer, che poi va importato tra le autorità di certificazione attendibili del browser (in Firefox: Impostazioni > Privacy e sicurezza > Certificati > Mostra certificati > Autorità > Importa).

Fatto questo, si configura il browser per usare come proxy HTTP e HTTPS l’indirizzo 127.0.0.1 sulla porta 8080 (o quella scelta in fase di avvio). Da questo momento ogni richiesta effettuata dal browser passa attraverso ZAP e compare nella scheda Storia, pronta per essere analizzata, ripetuta o inviata al modulo di scansione attiva.

Passo 5-6: il primo Automated Scan su un’applicazione web

Il modo più rapido per iniziare è la funzione Automated Scan integrata nell’interfaccia desktop: si inserisce l’URL del bersaglio, si sceglie se usare anche lo Spider AJAX (utile per applicazioni JavaScript pesanti come quelle costruite con React o Vue) e si avvia. ZAP prima esegue una scansione passiva (Spider) per mappare tutte le pagine e i punti di ingresso, poi passa alla scansione attiva, che invia payload di test per individuare vulnerabilità come SQL injection, cross-site scripting o header di sicurezza mancanti.

Durante questa prima scansione conviene tenere d’occhio la scheda Spider per verificare quante pagine sono state effettivamente trovate: se il numero è sorprendentemente basso rispetto alle aspettative, quasi sempre significa che l’applicazione usa routing lato client (single-page application) e serve attivare lo Spider AJAX, che simula un browser reale con motore JavaScript per seguire i link generati dinamicamente invece di limitarsi al markup HTML statico.

Per chi lavora da riga di comando, lo stesso risultato si ottiene con lo script baseline, pensato apposta per pipeline automatiche dove serve un controllo rapido e non troppo invasivo:

docker run -t ghcr.io/zaproxy/zaproxy:stable zap-baseline.py \
  -t https://staging.tuosito.it \
  -r report-baseline.html \
  -w report-baseline.md \
  -x report-baseline.xml

Il flag -t indica il bersaglio, -r genera un report HTML leggibile, -w produce un riepilogo in Markdown comodo da allegare a una pull request e -x restituisce l’output in XML per l’integrazione con altri strumenti.

Passo 7-8: testare le API REST con l’import OpenAPI

Testare un’API richiede un passaggio in più rispetto a un sito web tradizionale, perché lo Spider da solo non riesce a “scoprire” endpoint che non sono collegati da link HTML. La soluzione è importare la definizione OpenAPI (o Swagger) del servizio: da Importa > Definizione OpenAPI, ZAP legge il file JSON o YAML e genera automaticamente tutte le richieste verso gli endpoint documentati, con i relativi metodi HTTP e parametri.

Una volta importata la definizione, si può lanciare una scansione attiva mirata solo su quel contesto tramite l’API REST di ZAP, utile quando si vuole automatizzare il test senza passare dall’interfaccia grafica:

curl "http://localhost:8080/JSON/openapi/action/importUrl/?apikey=LA_TUA_API_KEY&url=https://staging.tuoservizio.it/openapi.json"

curl "http://localhost:8080/JSON/ascan/action/scan/?apikey=LA_TUA_API_KEY&url=https://staging.tuoservizio.it/&recurse=true&inScopeOnly=false"

Il primo comando importa lo schema, il secondo avvia la scansione attiva vera e propria. È qui che vale la pena ricordare un punto sottovalutato: se l’API applica rate limiting o quote per chiave, una scansione attiva a piena velocità può far scattare blocchi o errori 429, restituendo un falso quadro di “endpoint irraggiungibile” invece che dati utili sulla sicurezza.

Passo 9-10: scansione autenticata e gestione delle sessioni

Gran parte delle applicazioni reali nasconde le funzionalità più sensibili dietro un login, e uno scan non autenticato lascia scoperta proprio la parte più critica del sistema. ZAP gestisce l’autenticazione tramite il concetto di Contesto: si definisce l’URL di login, i campi del form (o gli endpoint dell’API di autenticazione, se si tratta di un token JWT o OAuth), e si indica come riconoscere una sessione scaduta.

Per le API moderne basate su token, l’opzione più affidabile è lo script di autenticazione personalizzato (in formato Zest o JavaScript), che replica la chiamata di login, estrae il token dalla risposta e lo inietta come header Authorization in ogni richiesta successiva della scansione. Senza questo passaggio, ZAP testerà solo le pagine pubbliche, dando una falsa sensazione di sicurezza.

Un dettaglio spesso trascurato riguarda gli utenti multipli: se l’applicazione distingue tra ruoli diversi (per esempio utente normale e amministratore), conviene configurare due contesti separati con due utenti distinti, e confrontare i risultati delle due scansioni. Molte vulnerabilità di controllo degli accessi emergono proprio dal confronto tra ciò che un utente a basso privilegio riesce a raggiungere e ciò che dovrebbe essere riservato solo all’amministratore, un tipo di verifica che una singola scansione con un solo profilo non può rilevare.

Passo 11: Automation Framework per scansioni ripetibili

L’Automation Framework è l’add-on che rende ZAP adatto a un uso professionale continuativo: invece di ripetere manualmente ogni configurazione, si scrive un file YAML che descrive contesto, job di spider, scansione attiva e generazione del report. Con l’aggiornamento di maggio 2026 l’add-on Automation Framework è arrivato alla versione 0.60.0, mentre il componente Client Side Integration (per testare applicazioni con molto JavaScript lato client) è alla 0.26.0.

env:
  contexts:
    - name: "contesto-demo"
      urls:
        - "https://staging.tuosito.it"
      authentication:
        method: "script"
        parameters:
          script: "auth-jwt.js"
jobs:
  - type: spider
    parameters:
      context: "contesto-demo"
      url: "https://staging.tuosito.it"
      maxDuration: 5
  - type: activeScan
    parameters:
      context: "contesto-demo"
      policy: "API-Scan-Policy"
  - type: report
    parameters:
      template: "traditional-html"
      reportDir: "/zap/wrk/report"
      reportFile: "report-automation"

Questo file si esegue con il comando zap.sh -cmd -autorun zap-automation.yaml oppure tramite l’immagine Docker, ed è lo stesso identico approccio che poi si riusa nella pipeline CI/CD del passo successivo: si scrive una volta e si esegue ovunque, dal laptop dello sviluppatore al server di build.

Passo 12: integrare ZAP in una pipeline CI/CD con GitHub Actions

Il valore reale del security testing si vede quando smette di essere un’attività occasionale e diventa parte del ciclo di rilascio. GitHub mette a disposizione action ufficiali mantenute dal progetto ZAP, sia per la scansione baseline sia per quella dedicata alle API:

name: Scansione di sicurezza API con ZAP
on:
  pull_request:
    branches: [main]
jobs:
  zap_api_scan:
    runs-on: ubuntu-latest
    steps:
      - name: Esegui ZAP API Scan
        uses: zaproxy/[email protected]
        with:
          target: 'https://staging.tuoservizio.it/openapi.json'
          format: openapi
          fail_action: true
          cmd_options: '-a'

L’opzione fail_action: true fa fallire la pull request se ZAP trova alert di livello alto, trasformando la scansione da report informativo a controllo di qualità vero e proprio. Per progetti con budget di tempo limitato in CI, conviene partire con la action baseline (più veloce) e passare alla full scan solo nelle build notturne o settimanali.

Leggere il report: rischio, confidenza e priorità

Ogni alert generato da ZAP combina due assi: il livello di rischio (quanto è grave, se confermata) e il livello di confidenza (quanto è probabile che sia un vero positivo). Capire questa distinzione è essenziale per non sprecare tempo del team di sviluppo dietro a falsi allarmi, ma anche per non archiviare per errore un problema reale con confidenza bassa.

Livello di rischio	Significato pratico	Esempio tipico di alert
Alto (High)	Sfruttabile con impatto diretto su dati o sistema	SQL injection, RCE, autenticazione bypassata
Medio (Medium)	Rischio concreto ma con condizioni aggiuntive	Cross-site scripting riflesso, cookie senza flag Secure
Basso (Low)	Debolezza minore o difesa in profondità mancante	Header X-Content-Type-Options assente
Informativo	Nessun rischio diretto, utile per hardening	Versione del server esposta nell’header

Un output tipico di un singolo alert, se estratto in formato JSON dall’API di ZAP, si presenta così:

{
  "alert": "SQL Injection",
  "risk": "High",
  "confidence": "Medium",
  "url": "https://staging.tuoservizio.it/api/utenti?id=1",
  "param": "id",
  "cweid": "89",
  "wascid": "19",
  "solution": "Usare query parametrizzate o un ORM con binding sicuro dei parametri"
}

Sul fronte della confidenza, ZAP usa quattro livelli: Low, Medium, High e Confirmed. Un alert Low indica che il pattern osservato potrebbe essere un falso positivo dovuto al comportamento specifico dell’applicazione; High significa che il test ha una probabilità molto bassa di sbagliarsi; Confirmed è riservato ai casi in cui ZAP ha verificato attivamente lo sfruttamento, per esempio confermando che una query SQL modificata ha effettivamente alterato la risposta del server. La regola pratica che molti team adottano è semplice: bloccare la pipeline solo sugli alert High con confidenza almeno Medium, e trattare tutto il resto come backlog da smaltire con priorità inferiore, senza fermare i rilasci.

Modalità di scansione a confronto

ZAP offre più modalità operative, e scegliere quella sbagliata è una delle cause più comuni di risultati inutili o di scansioni che durano ore senza motivo. La tabella seguente riassume quando usare ciascuna modalità.

Modalità	Come si lancia	Quando usarla	Durata tipica
Baseline scan	zap-baseline.py	Controllo rapido a ogni pull request	1-3 minuti
Full scan (Active)	zap-full-scan.py o Automated Scan	Build notturne o rilasci pianificati	15 minuti – alcune ore
API scan	zap-api-scan.py o action-api-scan	Servizi REST/GraphQL con schema OpenAPI	5-30 minuti
Automation Framework	file YAML con -autorun	Configurazioni complesse e ripetibili	Variabile, dipende dai job

Sei errori comuni da evitare con OWASP ZAP

Chi inizia a usare ZAP tende a ripetere sempre gli stessi errori, e conoscerli in anticipo fa risparmiare ore di debug. Ecco i più frequenti riscontrati da chi integra lo strumento in ambienti reali.

Lanciare una scansione attiva in produzione senza autorizzazione scritta. Anche un test “leggero” può generare traffico anomalo, riempire log, o nei casi peggiori inserire dati di test in un database reale.
Saltare la configurazione dell’autenticazione. Uno scan non autenticato copre spesso meno del 20% delle funzionalità reali di un’applicazione con login.
Confondere Spider e Active Scan. Lo Spider si limita a mappare le pagine, non invia payload pericolosi; l’Active Scan invece inietta dati di attacco e può modificare stato applicativo se non isolato correttamente.
Non aggiornare gli add-on dal Marketplace. Versioni vecchie di componenti come Automation Framework possono mancare di correzioni di sicurezza importanti, vanificando l’obiettivo stesso dello strumento.
Ignorare il rate limiting delle API testate. Una scansione a piena velocità contro un’API con quota genera solo errori 429, non risultati di sicurezza affidabili.
Bloccare ogni pull request per alert Informational. Trattare ogni alert allo stesso modo, senza filtrare per rischio e confidenza, porta il team a ignorare la pipeline di sicurezza nel giro di poche settimane.

Risoluzione dei problemi più comuni

Anche seguendo tutti i passi correttamente, capita di incontrare ostacoli tecnici. Ecco una lista di problemi ricorrenti e le relative soluzioni verificate.

“Unable to access jarfile zap.jar” all’avvio. Verificare che il percorso di installazione non contenga spazi o caratteri speciali e che si stia lanciando lo script dalla cartella corretta.
Il browser non intercetta il traffico HTTPS. Il certificato root di ZAP non è stato importato correttamente tra le autorità di certificazione attendibili: rigenerarlo da Opzioni e reimportarlo.
Errore “Address already in use” sulla porta 8080. Un altro processo occupa già la porta: cambiarla con -port 8090 oppure terminare il processo in conflitto.
L’Active Scan resta bloccata allo 0%. Controllare che lo Spider abbia effettivamente trovato URL in scope; se il sito usa molto JavaScript, attivare lo Spider AJAX.
Troppi falsi positivi sugli stessi alert. Creare una regola di Alert Filter per declassare o ignorare pattern noti e non applicabili al proprio stack.
L’importazione dello schema OpenAPI fallisce. Validare prima il file con uno strumento come swagger-cli: schemi malformati vengono spesso rifiutati silenziosamente.
Il job GitHub Actions va in timeout. Aumentare il parametro timeout-minutes del job e, se possibile, sostituire la full scan con la baseline scan nelle pull request frequenti.
La scansione autenticata perde la sessione a metà. Impostare correttamente l’indicatore di “sessione scaduta” nel contesto, così ZAP può ri-autenticarsi automaticamente durante lo scan.
Errore OutOfMemoryError su siti grandi. Aumentare l’heap Java con la variabile JAVA_OPTS=-Xmx4096m prima di avviare ZAP.
Il report HTML risulta vuoto. Verificare i permessi di scrittura della cartella di output, specialmente quando ZAP gira dentro un container Docker con utente non root.

Consigli avanzati per un uso professionale

Una volta padroneggiati i passaggi base, ci sono alcune pratiche che fanno davvero la differenza in un contesto aziendale. La prima è separare le policy di scansione: usare una policy “leggera” (meno test, più veloce) per le pull request e una policy completa per le esecuzioni pianificate, così da bilanciare velocità del team e profondità dell’analisi.

La seconda riguarda lo scripting: ZAP supporta script in Zest, JavaScript e Python per personalizzare autenticazione, filtri e persino nuovi tipi di test attivi. Chi gestisce più applicazioni con lo stesso schema di login può scrivere uno script di autenticazione riutilizzabile e versionarlo insieme al codice, così la configurazione del test di sicurezza segue lo stesso ciclo di vita del software che protegge.

Terzo consiglio: usate sempre l’immagine Docker “stable” per gli ambienti di produzione della pipeline e riservate le immagini “weekly” (con gli aggiornamenti più recenti degli add-on) agli ambienti di test interni, dove un’eventuale regressione non blocca i rilasci reali. Infine, integrate ZAP con uno strumento di analisi statica del codice (SAST): la scansione dinamica di ZAP trova ciò che è raggiungibile a runtime, mentre il SAST individua pattern di codice pericolosi anche in percorsi non ancora coperti dai test, offrendo una copertura complementare. Chi vuole approfondire i test manuali con interfaccia interattiva può confrontare questo approccio con la nostra guida a Burp Suite, utile per capire quando preferire un tool interattivo a uno automatizzato.

Un ultimo accorgimento riguarda la gestione degli scope: definite sempre in modo esplicito quali host, sottodomini e porte rientrano nel test, escludendo per default tutto il resto. È un dettaglio che sembra banale ma che evita l’incidente più imbarazzante nel mondo del security testing: uno scan attivo che, seguendo un link esterno non filtrato, finisce per colpire un dominio di terzi mai autorizzato.

Tuning delle performance: thread, timeout e profondità

Su applicazioni di dimensioni medio-grandi, la configurazione predefinita di ZAP spesso non è quella ottimale. Nelle Opzioni della scansione attiva si può aumentare il numero di thread concorrenti (con moderazione, per non sovraccaricare il server bersaglio o la rete), ridurre il timeout per richiesta se il backend risponde velocemente, e limitare la profondità dello Spider quando l’applicazione ha una struttura ad albero molto ampia ma poco profonda, come accade spesso nei cataloghi e-commerce. Un buon punto di partenza per un ambiente CI condiviso è impostare tra 2 e 5 thread e un timeout di 10-15 secondi, per poi affinare i valori osservando i tempi reali di esecuzione nelle prime build.

ZAP rispetto ad altri approcci al testing delle API

Vale la pena inquadrare ZAP dentro il panorama più ampio del security testing applicativo. Materiale divulgativo pubblicato da HackerOne nel proprio knowledge center dedicato a ZAP lo descrive come uno strumento particolarmente adatto a chi vuole introdurre test di sicurezza automatizzati senza passare da subito per un programma completo di bug bounty o pentest professionale: la scansione automatica copre le classi di vulnerabilità più note, mentre le verifiche più sottili restano appannaggio di un ricercatore umano o di un team di pentest dedicato.

Un’analisi simile, pubblicata sul blog di StackHawk dedicato all’application security testing con ZAP, sottolinea come lo strumento si presti bene a un uso “shift-left”, cioè spostato il più possibile a inizio pipeline, proprio grazie alla possibilità di automatizzarlo completamente via YAML e CLI senza bisogno di un operatore che segua manualmente ogni scansione. Questo è anche il motivo per cui molte aziende lo affiancano, e non lo contrappongono, a strumenti di dependency scanning e SAST: ciascuno copre una fetta diversa della superficie di attacco.

Un progetto completo funzionante: dalla API al report in pipeline

Mettendo insieme tutti i passaggi visti finora, un progetto reale e riutilizzabile si struttura in quattro parti che vivono nello stesso repository Git: l’applicazione o l’API da testare, il file di configurazione dell’Automation Framework, lo script di autenticazione e il workflow CI/CD.

La struttura tipica delle cartelle è questa:

progetto/
├── src/                     # codice dell'applicazione o API
├── zap/
│   ├── zap-automation.yaml  # configurazione Automation Framework
│   ├── auth-jwt.js          # script di autenticazione riutilizzabile
│   └── policies/
│       └── api-scan-policy.policy
├── .github/
│   └── workflows/
│       └── zap-security-scan.yml
└── docker-compose.yml       # ambiente di staging effimero per i test

Il file docker-compose.yml si occupa di alzare l’applicazione da testare insieme a ZAP in modalità daemon, sulla stessa rete virtuale, in modo che il workflow CI/CD possa orchestrare entrambi con un solo comando:

services:
  app:
    build: ./src
    ports:
      - "3000:3000"
  zap:
    image: ghcr.io/zaproxy/zaproxy:stable
    depends_on:
      - app
    command: zap-api-scan.py -t http://app:3000/openapi.json -f openapi -r /zap/wrk/report.html
    volumes:
      - ./zap/report:/zap/wrk

Il flusso completo funziona così: a ogni pull request, GitHub Actions avvia con docker-compose un ambiente di staging effimero, esegue la baseline scan di ZAP contro quell’ambiente e pubblica il report Markdown come commento sulla pull request. Alla fusione sul branch principale, un secondo workflow pianificato esegue la scansione completa con l’Automation Framework, incluso il test autenticato delle API, e archivia il report HTML come artefatto della build per la revisione del team di sicurezza. Questo schema, replicabile su qualsiasi stack (Node.js, Java, Python, PHP), è esattamente il tipo di automazione che trasforma ZAP da tool occasionale a componente stabile del ciclo di rilascio. Chi ha già una API gateway sicura in Node.js può agganciare questo workflow direttamente allo stesso repository, senza dover duplicare la configurazione di rete.

ZAP nel contesto normativo europeo

Per le aziende italiane ed europee, testare regolarmente le proprie applicazioni non è solo buona pratica tecnica: rientra sempre più spesso tra le aspettative implicite di normative come NIS2 e Cyber Resilience Act, che richiedono processi documentati di gestione delle vulnerabilità. Uno strumento gratuito come ZAP, integrato in pipeline con report versionati, offre una traccia concreta e ripetibile di quando e come sono stati eseguiti i test, utile sia in fase di audit interno sia in caso di richieste da parte delle autorità di vigilanza. Non sostituisce un penetration test professionale con analisi manuale, ma copre in automatico una parte significativa dei controlli di base richiesti. Per chi vuole abbinare la scansione dinamica a una mappatura sistematica delle vulnerabilità note, vale la pena leggere anche la nostra guida a Nmap per la scansione di rete e il confronto tra OWASP Top 10 e API Security Top 10, che aiuta a dare priorità agli alert generati da ZAP in base alle categorie di rischio più diffuse.

Chi lavora prevalentemente su applicazioni Node.js può inoltre confrontare i risultati ottenuti con ZAP con la nostra guida su come implementare le difese OWASP Top 10 in Node.js, così da chiudere il cerchio tra scansione dinamica e correzione del codice.

Messi insieme, i dodici passaggi di questa guida coprono l’intero ciclo di vita del security testing con ZAP: installazione verificata, configurazione del proxy, prima scansione, test mirato delle API, autenticazione multi-ruolo, automazione riproducibile e infine integrazione nella pipeline di rilascio. Non serve implementarli tutti il primo giorno: anche solo aggiungere una baseline scan automatica a ogni pull request rappresenta un salto di qualità rispetto a non avere alcun controllo dinamico prima del deploy in produzione.

Domande frequenti su OWASP ZAP

OWASP ZAP è davvero gratuito anche per uso aziendale?
Sì. ZAP è distribuito con licenza Apache 2.0 ed è completamente gratuito, incluse le funzionalità di scansione attiva, l’Automation Framework e l’integrazione CI/CD, senza limiti di utilizzo commerciale.

Posso usare ZAP su qualsiasi sito web?
No. Va usato solo su applicazioni proprie o per cui si ha un’autorizzazione scritta esplicita. Scansionare sistemi di terzi senza consenso può costituire reato di accesso abusivo a sistema informatico.

Qual è la differenza principale tra ZAP e uno scanner commerciale a pagamento?
ZAP è open source e gratuito in ogni sua funzione, incluse la scansione attiva completa e l’Automation Framework, mentre molti prodotti commerciali riservano queste capacità alle edizioni Professional o Enterprise a pagamento.

ZAP riesce a testare API GraphQL?
Sì, tramite l’add-on dedicato che importa lo schema GraphQL (introspection) e genera automaticamente query e mutation di test, in modo simile a quanto avviene con l’import OpenAPI per le API REST.

Quanto tempo richiede una scansione completa?
Dipende dalle dimensioni dell’applicazione: una baseline scan richiede in genere pochi minuti, mentre una full active scan su un’applicazione medio-grande può richiedere da 15 minuti a diverse ore, a seconda del numero di endpoint e della policy scelta.

ZAP può sostituire un penetration test professionale?
No. ZAP automatizza test noti e ripetibili, ma non ha il ragionamento contestuale di un tester umano esperto, che può scoprire logiche di business difettose o catene di vulnerabilità non individuabili da uno scanner. I due approcci si completano, non si sostituiscono.

Come aggiorno ZAP alla versione più recente?
Dall’interfaccia desktop, tramite il Marketplace degli add-on che segnala automaticamente gli aggiornamenti, oppure scaricando il nuovo installer dal sito ufficiale. Per Docker basta effettuare il pull dell’immagine con il tag “stable” più recente.

ZAP funziona anche su applicazioni mobile?
Indirettamente sì: configurando il proxy dell’app mobile (Android o iOS) verso ZAP, è possibile intercettare e analizzare le chiamate API che l’app effettua verso il backend, anche se ZAP non analizza il codice nativo dell’app in sé.

Meglio iniziare con la baseline scan o direttamente con la full scan?
Conviene sempre partire dalla baseline scan, che è passiva e sicura anche su ambienti condivisi, per prendere confidenza con l’interfaccia e i primi report. La full scan attiva va introdotta solo dopo aver definito uno scope preciso e un ambiente di staging dedicato, dato che invia payload di attacco reali contro l’applicazione.

OWASP ZAP 2.17: Testa le API in 12 Passi [2026]