OWASP ZAP
The world's most popular free web app security scanner. Automated and manual testing with a powerful proxy for finding vulnerabilities.
Overview
OWASP Zed Attack Proxy (ZAP) is a free, open-source web application security scanner maintained by the Open Web Application Security Project (OWASP). First released in 2010, ZAP is the most widely used security testing tool in the world. It functions as a proxy that sits between the browser and the web application, intercepting and modifying requests to identify security vulnerabilities.
ZAP supports both automated scanning (spidering a site and running a suite of vulnerability checks) and manual testing (intercepting and modifying requests on the fly). It is an essential tool for any team that takes application security seriously.
What it's used for
ZAP is essential for:
- Automated vulnerability scanning: Spider a web app and automatically detect SQL injection, XSS, CSRF, and more.
- Manual penetration testing: Intercept requests, modify parameters, and probe for vulnerabilities interactively.
- CI/CD security gates: Run ZAP in headless mode as part of the deployment pipeline.
- API security testing: Scan REST and GraphQL APIs for common vulnerabilities.
- Developer security awareness: Free tool that every developer can run locally.
Pros & Cons
Pros
- Free and open source — no cost barrier
- Most popular security scanner with massive community
- Both automated and manual testing modes
- Extensive scripting and automation support
- Active development with regular updates
Cons
- Can generate false positives — requires manual review
- Scanning can be slow on large applications
- No enterprise support (community support only)
- Requires security knowledge to interpret results
- Some advanced features have a learning curve
Platforms & Integrations
ZAP runs on Windows, macOS, and Linux. It requires Java 11+. It can run as a desktop app, a command-line tool, or a Docker container.
Pricing
| Tier | Cost | Includes |
|---|---|---|
| Open Source | Free | Full scanner, all features, community support |
NZ Context
ZAP is the security tool most NZ software professionals should know. It is free, well-documented, and covers the OWASP Top 10 vulnerabilities. The NZ Government's NZ Information Security Manual references OWASP tools for web application security assessments. For NZ teams on a budget, ZAP provides enterprise-grade scanning at zero cost.
Alternatives
When to choose OWASP ZAP
A quick decision guide for NZ teams evaluating security testing options.
| Choose OWASP ZAP when… | Choose something else when… | Combine with… |
|---|---|---|
| Your team is building or testing a web app and budget is zero — ZAP is the only production-grade scanner that costs nothing | You need deep manual penetration testing with a polished workflow — choose Burp Suite Professional instead | SonarQube — ZAP finds runtime vulnerabilities; SonarQube finds them in source code before the app even runs |
| You need a security gate in CI/CD — ZAP's Docker image and GitHub Actions integration make headless scans straightforward | Your primary concern is dependency and container vulnerabilities rather than running-app behaviour — choose Snyk | Snyk — ZAP covers OWASP Top 10 at runtime; Snyk covers third-party library CVEs at build time |
| Your team is scanning REST or GraphQL APIs — ZAP supports OpenAPI import and can scan APIs without a browser | You need enterprise support SLAs or compliance audit trails — choose a commercial DAST platform such as Invicti or StackHawk | Selenium or Playwright — drive authenticated journeys through ZAP's proxy so the scanner sees pages behind login |
| You are preparing for an NZISM or PCI-DSS assessment — ZAP maps directly to OWASP Top 10, which those frameworks reference | You are testing a thick-client desktop or mobile app with no HTTP surface — ZAP is a web proxy and will find nothing | Burp Suite Community — Burp's Repeater and Intruder complement ZAP's automation when manual probing is needed on a specific endpoint |
What I would do
Practitioner judgment on tool adoption, team onboarding, and when to swap.
zaproxy/action-full-scan action, point it at the staging environment, and set it to fail the build on High-severity findings. That closes the gap between annual pen tests without any licensing cost. I would then spend one sprint triaging the initial scan results so the team learns which findings are real versus false positives before trusting the gate.The bottom line: ZAP's value is not the initial scan — it is the continuous scan. The teams that get the most out of it are the ones who wire it into CI/CD and triage findings every sprint rather than treating it as a one-off pre-launch checkbox.
Interview questions
Questions you are likely to get if you list OWASP ZAP on your CV — with what interviewers are really testing for.
What is the difference between ZAP’s passive scan and active scan, and when would you use each?
What they’re really testing: Whether you understand that security testing has a risk dimension — passive scanning is safe in production; active scanning can corrupt data or trigger alerts on live systems.
Strong answer covers: Passive scan reads traffic without sending additional requests (safe anywhere); active scan probes with crafted payloads (only on test environments). Mention that NZ government or financial sector clients often restrict active scanning to UAT environments only, and that you always get written sign-off before running an active scan on any environment that holds real customer data.
When would you choose OWASP ZAP over Burp Suite, and when would you go the other way?
What they’re really testing: Whether you know both tools well enough to make a reasoned trade-off rather than defaulting to one because it’s familiar.
Strong answer covers: ZAP for CI/CD automation and zero-cost scanning (strong case at NZ startups or government agencies with no security tooling budget); Burp Suite Professional for manual penetration testing where the Repeater, Intruder, and Collaborator features save hours. Mention that you’d use both together — ZAP for continuous scanning in the pipeline, Burp for deep manual probing on specific endpoints flagged by ZAP.
You’re a QA engineer at a NZ SaaS company. The CEO wants evidence of OWASP Top 10 coverage before your product goes live with a large retail client. How would you use ZAP to produce that evidence?
What they’re really testing: Whether you can translate a tool into a business deliverable, not just run commands and paste output.
Strong answer covers: Run a full active scan against UAT; export the HTML or XML report; map each ZAP alert category to the corresponding OWASP Top 10 item in a traceability matrix; triage findings by severity and document remediation status. Note that under the NZ Privacy Act 2020, any finding touching personal data handling (e.g., session fixation, IDOR) would be escalated to the Privacy Officer as well as the engineering lead.
Your ZAP active scan runs clean in CI, but a security consultant doing a manual pen test finds an SQL injection vulnerability on the same endpoint. How do you explain the gap?
What they’re really testing: Whether you understand ZAP’s limits as a DAST tool and can explain the difference between automated coverage and human judgment without getting defensive.
Strong answer covers: ZAP uses a fixed payload library — it may miss injection points that require multi-step navigation, custom session handling, or unusual encoding. Automated scanners also can’t reason about business logic. Explain you would review ZAP’s context configuration (did the scanner actually reach that endpoint?), update the scan policy or add a custom payload, and treat pen test findings as a signal to tune the automated scan rather than dismiss it.
How would you structure a ZAP scan for a React SPA that sits behind an OAuth2 login, where most of the sensitive API surface is only reachable after authentication?
What they’re really testing: Whether you can handle the authenticated scanning problem, which is where most real-world ZAP setups fall over.
Strong answer covers: Use a Playwright or Selenium script to perform the OAuth2 flow and then route all traffic through ZAP’s proxy so the scanner captures authenticated session tokens. Configure a ZAP Context with the bearer token or session cookie so the active scan can replay authenticated requests. Import the OpenAPI spec (if available) so ZAP knows the full API surface rather than relying solely on spider discovery. Exclude the logout and token-refresh endpoints from the scan scope to avoid mid-scan session loss.