OWASP ZAP just became a harder tool to ignore. The project shipped version 2.17.0 in December 2025, bumped its Java floor to version 17, added first-pass JWT support, and spent the first half of 2026 wiring its scan rules directly into the new OWASP Top 10:2025 categories. For a tool that costs nothing and runs the same in a laptop terminal as it does in a GitHub Actions pipeline, that is a meaningful upgrade cycle. This tutorial walks through installing OWASP ZAP 2.17.0, running your first scans, automating them with YAML, wiring them into CI/CD, and avoiding the mistakes that get teams flooded with false positives or, worse, banned from a target’s network for scanning without permission.
By the end you will have a working OWASP ZAP setup that runs locally, in Docker, and inside a GitHub Actions workflow, plus a repeatable automation framework plan you can drop into any web project.
Most application security programs lean on three overlapping tool categories: static analysis (SAST) that reads source code without running it, software composition analysis (SCA) that checks dependencies for known vulnerabilities, and dynamic analysis (DAST) that actually attacks a running application the way a real attacker would. OWASP ZAP sits squarely in that third category, and it is the only one of the three that catches issues only visible at runtime, things like misconfigured security headers, session handling bugs, and access control failures that only show up once a request actually hits a live server. That makes an OWASP ZAP setup a natural complement to whatever static scanning already runs in your pipeline, not a replacement for it.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What Is OWASP ZAP and Why It Matters in 2026
OWASP ZAP, short for Zed Attack Proxy, is a free dynamic application security testing (DAST) tool that sits between your browser and a target web application, intercepting and analyzing traffic for vulnerabilities. It started as a fork of the Paros proxy, moved under OWASP for years, and formally left the OWASP umbrella in 2023. Since September 2024, development has continued under Checkmarx sponsorship as “ZAP by Checkmarx,” but the project remains independently governed by the ZAP core team and stays free under the Apache License 2.0, with no paid tier, feature gate, or scan cap. That governance held through the 2.16.x line too: OWASP shipped ZAP 2.16.0 in January 2025 with a new spider and refreshed policy definitions, then followed it with ZAP 2.16.1 in March 2025 as a bug-fix and enhancement release, the kind of unglamorous maintenance update that signals a project still being actively run rather than coasting on a sponsor’s goodwill.
That governance detail matters for anyone deciding whether to commit engineering time to an OWASP ZAP setup: a project that changed sponsors without changing its license or its release cadence is a very different risk profile than a tool that could disappear behind a paywall next quarter. ZAP’s GitHub organization remains one of the more active security projects on GitHub, with the core repository and its dozens of add-on repositories seeing regular commits and monthly add-on releases throughout 2026 — 18 separate add-ons received updates in a single push in June 2026 alone, including the Client Side Integration add-on, which reached version 0.29 that same month — which is the cadence that produced the OWASP Top 10:2025 rule tagging, the JWT support, and the cloud metadata checks covered later in this guide.
The reason OWASP ZAP setup is worth revisiting right now is the pace of the 2.17.x release line. The core 2.17.0 build landed December 15, 2025, bringing core performance improvements and a meaningful cut to duplicate alert noise, and as of July 2026 it formally became the mandatory minimum baseline that every updated add-on must build against. Passive scanner rules v73 and active scanner rules v81, both released April 14, 2026, added tags mapping alerts directly to OWASP Top 10:2025 and the API Top 10 2023. Active scanner rules v80 added checks for cloud metadata exposure on IBM and OpenStack in March 2026. And in August 2026 the project shipped an LLM Support add-on, its first real answer to AI-assisted application testing.
None of that matters if you cannot get a scan running cleanly and reading its output correctly, so the rest of this guide is a straight path from zero to a working, automated OWASP ZAP pipeline.
Understanding ZAP’s Scan Types: Spider, AJAX Spider, Passive, and Active
Before installing anything, it helps to know what each ZAP component actually does, since the terminology trips up a lot of first-time users. The classic Spider crawls a site the way a search engine bot would: it follows hyperlinks in HTML, builds a map of every URL it finds, and adds each one to the Sites tree. It works well against traditional server-rendered pages but misses content that only appears after JavaScript runs, which is most modern single-page applications.
For those apps, ZAP offers the AJAX Spider (and, increasingly, the newer Client Spider covered later in this guide), which drives a real browser engine to execute JavaScript and capture routes a link-following crawler would never see. Passive scanning runs automatically and continuously in the background against every request ZAP observes, whether that traffic came from the spider, the AJAX Spider, or your own manual clicking around the app; it never sends attack payloads, only inspects what is already there, which is why it is safe to run against production. Active scanning is the one that actually attacks: it takes every parameter, header, and cookie the passive layers discovered and fires real exploit strings at each one, looking for the response differences that indicate a working SQL injection, a reflected XSS, or a dozen other vulnerability classes. Knowing which layer you are running at any given moment is the difference between a scan that safely audits a live site and one that accidentally starts attacking it.
Prerequisites: Versions, System Requirements, and What You Will Need
ZAP 2.16.0 and later, including the current 2.17.0 release, requires a minimum of Java 17. The Windows and Linux installers expect Java 17 or higher already on the system; the macOS package bundles a Zulu JRE so most Mac users skip a separate Java install entirely. Below is the full checklist before you start.
| Requirement | Minimum | Recommended | Notes |
|---|---|---|---|
| OWASP ZAP version | 2.17.0 | 2.17.0 (current stable) | Released December 15, 2025; all 2026 add-ons require it |
| Java runtime | Java 17 | Java 17 or newer | macOS installer bundles Zulu JRE 17 automatically |
| RAM | 4 GB | 8 GB or more | Active scans against large apps spike memory usage |
| Disk space | 1 GB free | 5 GB free | Session files and HTML reports grow fast on large targets |
| Operating system | Windows 10, macOS, 64-bit Linux | Windows 11, current macOS, Ubuntu 24.04 LTS | Docker images work identically across all three |
| Docker (optional) | Docker Engine 24.x | Docker Engine 26.x or newer | Needed only for the containerized workflow in Step 9 |
You will also need written authorization to scan your target. Active scanning sends real attack payloads, including SQL injection and cross-site scripting strings, at every parameter it finds. Running it against infrastructure you do not own or have explicit permission to test is a legal risk, not just a technical one. Stick to a staging environment, a deliberately vulnerable practice app, or a target where you have documented sign-off.
Step 1: Verify Java and Install OWASP ZAP 2.17.0
Start by confirming your Java version, since a mismatch here is the single most common install failure people report.
java -version
# Expect: openjdk version "17.0.x" or higher
# Ubuntu/Debian: install Java 17 if missing
sudo apt update && sudo apt install -y openjdk-17-jre
# Download ZAP 2.17.0 for Linux (installer method)
wget https://github.com/zaproxy/zaproxy/releases/download/v2.17.0/ZAP_2_17_0_unix.sh
chmod +x ZAP_2_17_0_unix.sh
./ZAP_2_17_0_unix.sh -q -dir /opt/zaproxy
# Launch ZAP from the install directory
/opt/zaproxy/zap.shOn Windows, download the ZAP 2.17.0 installer from the official ZAP downloads page and run it like any other installer; it will prompt you to point at an existing Java 17 install or use the bundled option if offered. On macOS, the .dmg package includes Java, so a double-click install is enough. If you would rather skip local installation entirely, jump ahead to the Docker section, since that path needs nothing but a working container runtime.
Step 2: Launch ZAP and Tour the Interface
On first launch, ZAP asks whether to persist the session to disk or run in memory only. For a one-off exploratory scan, memory-only is fine. For anything you want to revisit or hand off to a teammate, choose “Yes, I want to persist this session” and give it a name. The main window is split into three panels: the Sites tree on the left tracks every URL ZAP has seen, the top-right panel switches between the Quick Start tab, request/response viewers, and the Automation Framework tab, and the bottom panel streams the Alerts, History, and Spider progress in real time.
The fastest way to get oriented is the Quick Start tab. It exposes three buttons: Automated Scan, which chains a spider and an active scan against a URL you paste in; Manual Explore, which opens a ZAP-controlled browser — Microsoft Edge reached tier-1 support in July 2025, putting it on equal footing with Chrome and Firefox for exploring, crawling, and attacking — so you can click through the app yourself while ZAP records everything passively; and the newer HUD (Heads-Up Display) launch option, which overlays scan controls directly onto the page you are browsing. The HUD has not been deprecated or folded into another add-on as of the 2026 release notes, and it remains the easiest way to watch alerts fire in real time while you manually test a login flow or a multi-step checkout.
Step 3: Set Up a Context and Define Scope
Before running any scan wider than a quick exploratory pass, define a Context. Right-click your target in the Sites tree and choose “Include in Context,” then create a new context named after the application. This does two things: it stops ZAP from wandering off into third-party domains linked from your app (analytics scripts, CDNs, social widgets), and it gives you a place to attach authentication settings later in Step 11.
Inside the Context menu, set the Include and Exclude regex rules. A typical exclude list removes logout links, password-reset endpoints that send real emails, and any payment or checkout flow you do not want ZAP hammering with active scan payloads. Skipping this step is one of the most common reasons teams end up with a scan report full of noise from scanning marketing pages, CDN assets, and third-party trackers that were never the actual target.
Step 4: Run a Baseline (Passive) Scan
A baseline scan spiders the target to discover URLs, then runs ZAP’s passive scan rules against everything it captures, without sending any attack payloads. It is safe to run against production, since it never actively tries to break anything, and it is the standard first check for a CI/CD gate because it finishes in minutes rather than hours.
From the GUI, use Quick Start, paste the target URL, and select “Automated Scan” but leave the active scan toggle off. From the command line or a script, ZAP ships a baseline scan script you can call directly against the desktop install, or you can use the Docker image covered in Step 9, which is the more common path for this exact scan type.
Step 5: Run a Full Active Scan Safely
Active scanning is where ZAP earns its keep and where it can also cause real damage if pointed at the wrong target. After the spider finishes populating the Sites tree, right-click the target node and choose Attack, then Active Scan. ZAP will work through every discovered parameter, cookie, and header, trying SQL injection, cross-site scripting, path traversal, and dozens of other payload classes drawn from its active scan rule set.
Three settings matter here. First, thread count under Options > Active Scan controls concurrency; lower it if the target starts throwing errors or timing out. Second, the Policy tab lets you disable rule categories you do not care about, which both speeds up the scan and cuts irrelevant noise. Third, and most important for anything beyond a personal test app, confirm the scan is running against a context you scoped correctly in Step 3, because an unscoped active scan against a large site can run for hours and generate thousands of requests against endpoints nobody asked you to test.
Step 6: Triage Alerts Against OWASP Top 10:2025
Every finding lands in the Alerts panel, grouped by risk: High, Medium, Low, and Informational. As of the 2.17.0 rule updates shipped through April 2026, ZAP tags each alert against the current OWASP Top 10:2025 categories, which reshuffled the 2021 list in a few important ways. Security Misconfiguration jumped from fifth place to second. Software Supply Chain Failures is an entirely new category debuting at third. And a new tenth category, Mishandling of Exceptional Conditions, replaced Server-Side Request Forgery as a standalone entry, folding SSRF-style issues into other categories instead.
| Rank | OWASP Top 10:2025 Category | Typical ZAP Alert Focus |
|---|---|---|
| A01 | Broken Access Control | Missing authorization checks, path traversal, forced browsing |
| A02 | Security Misconfiguration | Verbose error pages, exposed source (.git, .svn), missing security headers |
| A03 | Software Supply Chain Failures | Outdated JS libraries flagged by the Retire.js add-on |
| A04 | Cryptographic Failures | Weak TLS configuration, cleartext credential transmission |
| A05 | Injection | SQL injection, command injection, XSS active scan rules |
| A06 | Insecure Design | Predictable resource locations, weak session design |
| A07 | Authentication Failures | Session fixation, weak login throttling, credential stuffing exposure |
| A08 | Software or Data Integrity Failures | Insecure deserialization, unsigned update checks |
| A09 | Security Logging and Alerting Failures | Passive checks for missing audit trails on sensitive actions |
| A10 | Mishandling of Exceptional Conditions | Stack traces in responses, inconsistent error handling |
Work High findings first, confirm each one manually before filing it (ZAP’s academic benchmark results put its false-positive rate noticeably above commercial tools in side-by-side testing, more on that later), and use the alert’s linked CWE reference to hand developers something more actionable than a raw scanner output.
Step 7: Build an Automation Framework YAML Plan
Clicking through the GUI does not scale past a single manual test. The Automation Framework, ZAP’s YAML-driven orchestration layer now at version 0.60.0 following a May 2026 release that improved automated setup workflows, is how every serious OWASP ZAP setup runs in practice. A plan file defines a context, a target URL, and an ordered list of jobs.
env:
contexts:
- name: "my-app"
urls:
- "https://staging.example.com"
jobs:
- type: spider
parameters:
maxChildren: 10
- type: passiveScan-wait
parameters:
maxDuration: 5
- type: activeScan
parameters:
maxScansInUI: 1
- type: report
parameters:
template: "traditional-html"
reportDir: "./reports"
reportFile: "zap-report-{{date}}.html"Run the plan with the ZAP CLI directly, using the -cmd flag to skip the GUI entirely:
zap.sh -cmd -autorun plan.yamlThis same YAML plan is the file you will hand to both the Docker image and the GitHub Actions workflow in the next two steps, so it is worth getting this file right once rather than maintaining three separate scan configurations.
Step 8: Run ZAP in Docker
Docker is now the more common way teams run OWASP ZAP, and ZAP’s own statistics page notes that direct downloads have been declining as container usage grows. The modern image lives under the zaproxy namespace; the older owasp/zap2docker-stable naming is still referenced in plenty of tutorials but points at legacy tags, so pin an explicit version rather than copying an old command verbatim.
# Baseline (passive-only) scan against a target
docker run --rm -v $(pwd)/reports:/zap/wrk/:rw \
zaproxy/zap-stable:2.17.0 \
zap-baseline.py -t https://staging.example.com \
-r baseline-report.html
# Full active scan using your Automation Framework plan
docker run --rm -v $(pwd):/zap/wrk/:rw \
zaproxy/zap-stable:2.17.0 \
zap.sh -cmd -autorun /zap/wrk/plan.yamlMounting a local directory to /zap/wrk/ is what lets the report land back on your host filesystem instead of disappearing inside the container. If your reports directory ends up empty after a run that otherwise completed, that mount path is the first thing to check.
Step 9: Integrate ZAP Into GitHub Actions
ZAP publishes four official GitHub Actions: action-baseline for the passive-only scan, action-full-scan for spider plus active scan, action-api-scan for OpenAPI and GraphQL-defined APIs, and action-af for running a full Automation Framework YAML plan from CI. A baseline scan on every pull request is the version most teams start with, since it runs fast enough to not block a merge queue.
name: OWASP ZAP Baseline Scan
on:
pull_request:
branches: [main]
jobs:
zap_scan:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: OWASP ZAP Baseline Scan
uses: zaproxy/[email protected]
with:
target: 'https://staging.example.com'
cmd_options: '-a'
fail_action: trueSet fail_action to true once you have tuned out the false positives, so the workflow actually blocks a merge on new High findings instead of just posting a report nobody reads. For a deeper nightly check, swap action-baseline for action-full-scan on a schedule trigger rather than on every pull request, since a full active scan takes considerably longer and is not something you want gating every commit.
Step 10: Handle Authenticated Scans
Most real applications sit behind a login, and an unauthenticated scan only tests the small slice of the app visible before sign-in. Add authentication to the Context you created in Step 3: open Context > Authentication, choose the method that matches your app (form-based, JSON-based, or script-based for anything using a custom flow like a multi-step login or a passkey challenge), and supply the login URL along with the field names ZAP should populate.
Then create a User under Context > Users with valid test credentials, and set that user in the Automation Framework plan so every job in the chain runs authenticated:
env:
contexts:
- name: "my-app"
urls:
- "https://staging.example.com"
authentication:
method: "form"
parameters:
loginPageUrl: "https://staging.example.com/login"
loginRequestUrl: "https://staging.example.com/login"
loginRequestBody: "username={%username%}&password={%password%}"
users:
- name: "test-user"
credentials:
username: "[email protected]"
password: "REPLACE_WITH_ENV_VAR"
jobs:
- type: spider
parameters:
user: "test-user"Never hardcode real credentials into a committed YAML file; pull them from a secrets manager or CI environment variable at runtime instead.
Step 11: Update Add-ons and Patch Known CVEs
Running an outdated ZAP install is not just a missed-features problem, it is an active security risk. CVE-2026-57527 affects the ZAP ViewState add-on before version 4: an insecure deserialization flaw that lets an attacker who controls a proxied server achieve arbitrary code execution by embedding a malicious serialized Java object in a javax.faces.ViewState response parameter, scored 8.8 on CVSS 3.1. Separately, CVE-2026-57301 hits the Jenkins OWASP ZAP Plugin version 1.0.7 and earlier, also scored 8.8, letting anyone with Item/Configure permission on a Jenkins job execute arbitrary code on the controller rather than the assigned agent.
The ZAP project team wrote plainly in its June 2026 update post: “Please update all of your ZAP 2.17 add-ons now. If you are on an older version of ZAP, please update to 2.17 – older versions will be vulnerable to Remote Code Execution.” Open ZAP’s Manage Add-ons dialog (Tools menu), click Check for Updates, and update everything, particularly ViewState. If you run the Jenkins plugin, update it independently through the Jenkins plugin manager, since it does not ship as part of the core ZAP install.
Step 12: Build a Complete Working Project
Put the pieces together into a repeatable project structure. A typical repository layout looks like this: a zap/plan.yaml holding the Automation Framework configuration from Step 7 and Step 10, a .github/workflows/zap-baseline.yml running the fast passive check from Step 9 on every pull request, a .github/workflows/zap-full-nightly.yml running the full active scan from a scheduled trigger against a staging environment, and a reports/ directory (git-ignored) where HTML and JSON output land locally during development.
That combination gives a team fast feedback on every pull request, a deeper nightly sweep that catches issues the quick pass misses, and a single YAML source of truth for scan configuration instead of three drifting copies. It is the same pairing many security teams already use alongside broader vulnerability scanning workflows and CI/CD supply chain hardening, and it costs nothing beyond the compute minutes your CI already provides.
Exporting Reports and Feeding Alerts Into Your Issue Tracker
A scan that produces an HTML report nobody opens is not much better than no scan at all. The report job in the Automation Framework plan supports several output templates beyond traditional-html: json for machine-readable output you can parse in a follow-up script, xml for legacy tooling that expects it, and sarif for teams already using SARIF-based code scanning dashboards, including GitHub’s own code scanning tab. Swapping the template value is enough to change formats without touching the rest of the plan.
jobs:
- type: report
parameters:
template: "sarif-json"
reportDir: "./reports"
reportFile: "zap-results.sarif"With a SARIF file in hand, GitHub Actions can upload it directly to the repository’s Security tab using the standard github/codeql-action/upload-sarif action, which puts ZAP findings in the same place as any other code scanning alert your team already reviews. For teams on Jira, GitLab, or a different tracker, the JSON report format is straightforward to parse with a short script that files one ticket per High-risk alert, tagging each with its OWASP Top 10:2025 category and CWE ID so the assigned developer does not have to go digging through a raw HTML file to understand what needs fixing.
Common Pitfalls When Running OWASP ZAP
- Scanning without an authorized target. Active scan payloads are real attack traffic. Get written sign-off before pointing ZAP at anything you do not personally own, and never run it against production without a change window.
- Skipping the Context and Scope step. An unscoped scan wanders into third-party CDNs, analytics domains, and marketing pages, wasting time and generating a report full of findings nobody can act on.
- Treating every alert as confirmed. Academic benchmark comparisons in 2026 measured OWASP ZAP’s false-positive rate noticeably higher than commercial competitors on the same test targets; manually verify High findings before filing tickets.
- Running an unauthenticated scan and assuming full coverage. Without login credentials configured in the Context, ZAP only ever sees the public-facing slice of an application.
- Ignoring add-on updates. The ViewState RCE (CVE-2026-57527) and the Jenkins plugin RCE (CVE-2026-57301) both hit installs that skipped routine updates in 2026.
- Running a full active scan as a pull-request gate. Active scans can take hours against a large app; use the fast baseline scan for PR gating and reserve the full scan for a nightly or weekly schedule.
- Letting the report pile up unread. A scan report that nobody triages provides no security benefit at all. Pipe results into an issue tracker or a SARIF-backed dashboard, covered in the export section above, so findings actually reach the engineer who owns the affected code.
- Forgetting to exclude logout and destructive endpoints from scope. An active scan that stumbles onto a logout link or an account-deletion endpoint mid-crawl can log itself out repeatedly or destroy test data, both of which silently corrupt the rest of the scan’s results.
Troubleshooting OWASP ZAP
Most OWASP ZAP problems fall into one of three buckets: environment issues (wrong Java version, a stale Docker image tag), configuration issues (missing scope, missing authentication), or timing issues (running an active scan before the spider has anything to work with). Work through the table below before assuming a bug in ZAP itself, since the overwhelming majority of reported issues trace back to one of these known causes rather than a genuine defect in the scanner.
| Symptom | Likely Cause | Fix |
|---|---|---|
| ZAP fails to launch after install | Java version below 17 | Run java -version and install/upgrade to Java 17 or newer |
| Spider finds almost no URLs | Target requires JavaScript rendering | Use the AJAX Spider (or Client Spider automation) instead of the classic spider |
| Active scan finishes instantly with zero alerts | Spider was not run first, so no URLs were queued for the active scan | Always run spider or passiveScan-wait before the activeScan job |
| Docker container exits with permission errors on reports | Host directory mounted to /zap/wrk is not writable by the container user | chmod the reports directory or run with matching UID mapping |
| GitHub Actions workflow times out | Full active scan running on every pull request instead of a schedule | Switch PR triggers to action-baseline; reserve action-full-scan for nightly runs |
| Authenticated scan still shows login page content | Login indicator pattern not configured in the Context | Set a logged-in/logged-out regex indicator under Authentication settings |
| ZAP reports thousands of duplicate alerts | No scope defined, so ZAP is scanning every linked third-party domain | Add Include/Exclude regex rules under Context scope before scanning |
| Docker image pull fails or is very slow | Using the deprecated owasp/zap2docker-stable name on a slow mirror | Pull the current zaproxy/zap-stable:2.17.0 image directly instead |
| Add-on install fails with a compatibility error | Add-on version requires a newer ZAP core than what is installed | Update ZAP itself to 2.17.0 first, then retry the add-on update |
Advanced Tips: PTK, Client Spider, and the New LLM Support Add-on
Once the basic OWASP ZAP setup is running reliably, three additions are worth exploring. The PenTest Kit (PTK) browser extension, which advanced to beta version 0.7.0 in June 2026, integrates directly into a ZAP-controlled browser session and can be driven through the Automation Framework with a ptk.automatedScanning.enabled flag alongside a spiderClient job, giving you modern single-page-application coverage that the classic spider misses. The Client Spider itself, ZAP’s newer crawler built for JavaScript-heavy frontends, officially became the recommended crawler for modern apps in July 2026, now that the older AJAX Spider and DOM XSS add-ons have been pulled from the nightly and weekly builds.
The LLM Support add-on, which had its official launch in August 2026, is worth a look if your application exposes any AI-backed endpoints, since it adds detection paths oriented toward prompt-injection-style issues that traditional web scan rules were never built to catch. None of these three are required for a solid baseline pipeline, but they close real coverage gaps that a classic 2020-era ZAP install would have missed entirely.
OWASP ZAP vs Burp Suite: Which One Should You Use
The honest answer for most teams is both, used for different jobs. OWASP ZAP is free, automatable, and built to live inside CI/CD, which makes it the natural default for continuous scanning on every pull request. Burp Suite Professional costs around 499 dollars per user per year and leans on a human tester driving the tool interactively, with academic comparisons in 2025 and 2026 consistently finding it ahead on raw detection accuracy: one 2026 comparative study measured Burp Suite Professional at roughly 87.3 percent aggregate detection accuracy against ZAP’s lower score in the same test set, and a separate SQL injection-focused study found Burp hitting 96.92 percent accuracy on complex time-based blind injection scenarios versus 73.85 percent for ZAP.
| Factor | OWASP ZAP 2.17.0 | Burp Suite Professional |
|---|---|---|
| License cost | Free, Apache License 2.0 | Roughly $499 per user per year |
| Best fit | CI/CD automation, continuous DAST | Manual, expert-led penetration testing |
| Detection accuracy (academic benchmarks) | Lower in most 2025-2026 comparative studies | Higher aggregate accuracy, around 87 percent in one study |
| False-positive rate | Higher in the same benchmark studies | Lower in the same benchmark studies |
| Resource efficiency / speed | Faster in fuzzing benchmarks (about 4.72s in one test) | Slower in the same test (about 22.56s, Community edition) |
| CI/CD native tooling | Official GitHub Actions, Docker images, YAML automation | Requires separate CI integration tooling |
The practical pattern most security teams settle on: run OWASP ZAP automatically on every build to catch regressions cheaply, and bring in Burp Suite (or a human pentester using it) for periodic, deeper manual assessments where accuracy on complex, chained vulnerabilities matters more than automation cost. For teams evaluating broader scanner categories, this pairing sits alongside SAST, DAST, and SCA tooling decisions and network vulnerability scanners like Nessus and OpenVAS as part of a layered AppSec program. Teams already running Burp Suite or scanning containers with Trivy can slot ZAP in as the CI-native layer without replacing either tool.
Frequently Asked Questions
Is OWASP ZAP really free for commercial use?
Yes. OWASP ZAP ships under the Apache License 2.0, which permits commercial use, redistribution, and modification without payment. There is no Pro tier, no feature gate, and no scan cap; every capability covered in this tutorial, including the Automation Framework, Docker images, and GitHub Actions, is available at no cost.
What Java version does OWASP ZAP 2.17.0 require?
Java 17 or newer, for both the Windows and Linux installers. The macOS package bundles a compatible Java runtime, so most Mac users do not need a separate installation step.
Can I run OWASP ZAP without installing anything locally?
Yes. The official Docker image, zaproxy/zap-stable:2.17.0, runs the full scanner in a container with no local Java install required. This is the path most CI/CD pipelines use, as shown in Step 8 and Step 9 of this guide.
Is it legal to run an OWASP ZAP scan against a website?
Only against systems you own or have explicit written authorization to test. Active scanning sends real exploit payloads. Running it against third-party infrastructure without permission can violate computer misuse laws in most jurisdictions, regardless of intent.
How is OWASP ZAP different from Burp Suite?
ZAP is free, open source, and built around automation and CI/CD integration. Burp Suite Professional is a paid commercial tool generally used by human testers running interactive, manual assessments, and academic benchmarks in 2025 and 2026 have consistently measured it with higher raw detection accuracy on complex vulnerability classes. Many teams use both: ZAP for continuous automated scanning, Burp for periodic manual deep-dives.
Why did my active scan take several hours to finish?
Active scans test every discovered parameter with multiple payload classes, so scan time scales with the number of URLs and parameters found by the spider. Narrowing the Context scope, disabling irrelevant rule categories in the Policy tab, and excluding low-value URLs (logout links, static assets) are the most effective ways to cut scan time.
Does OWASP ZAP support scanning REST and GraphQL APIs?
Yes, through the dedicated action-api-scan GitHub Action and equivalent Automation Framework job type, which can import an OpenAPI specification or a GraphQL schema and drive the scan from that definition instead of relying on the spider to discover endpoints by crawling links. This complements broader API security testing practices covered elsewhere on this site.
What is the ZAP HUD and is it still supported in 2026?
The HUD (Heads-Up Display) overlays scan controls and live alert data directly onto the page you are browsing during a manual test. Unlike the AJAX Spider and DOM XSS add-ons, which were retired from nightly and weekly builds in 2026, ZAP’s own documentation and blog posts show no retirement notice for the HUD, and it remains available as a standard add-on in the 2.17.0 release line. It is particularly useful during the Manual Explore workflow from Step 2, since it lets you watch alerts populate in the browser itself rather than switching back and forth to the desktop Alerts panel while you click through a login flow or a checkout process.
