# OWASP ZAP
OWASP ZAP (Zed Attack Proxy) is a free, open-source web application security scanner maintained by the Open Worldwide Application Security Project. It exists because professional-grade web security testing tools historically carried licensing costs that excluded individual developers, small teams, and resource-constrained organizations. ZAP solves the access problem by delivering a full-featured intercepting proxy, active scanner, passive scanner, and automation framework at no cost. It functions as both a learning tool for practitioners entering application security and a production-grade instrument for security engineers running continuous testing pipelines. Its dual identity as a manual testing aid and a programmable automation engine makes it applicable across the full software development lifecycle, from local development through CI/CD deployment gates.
---
OWASP ZAP is an HTTP intercepting proxy and web application vulnerability scanner. Technically, it is a Java-based application that positions itself between a browser or API client and a target web application, inspecting and optionally modifying every HTTP and HTTPS request and response in transit. It identifies security weaknesses by combining passive traffic analysis with active attack simulation.
ZAP is distinct from network vulnerability scanners such as Nessus or OpenVAS, which operate at the network and service layer rather than the application layer. ZAP is not a static application security testing (SAST) tool; it does not analyze source code. It is a dynamic application security testing (DAST) tool, meaning it requires a running application to test. This distinguishes it from tools like Semgrep or SonarQube, which analyze code at rest.
ZAP is also not a web application firewall (WAF). A WAF blocks malicious traffic in production. ZAP generates that traffic in controlled environments to find vulnerabilities before attackers do.
Several operational modes exist within ZAP. Standard mode allows full scanning and manual testing. Safe mode restricts the tool to passive scanning only, preventing any potentially harmful requests. Protected mode limits active scanning to URLs within a defined scope. Attack mode automatically begins active scanning as soon as new targets are detected, intended for experienced practitioners who understand the risk of unsolicited active testing.
ZAP differs from its closest commercial analogue, Burp Suite Professional, primarily in licensing model and workflow. Burp Suite offers a more polished manual testing interface and some features ZAP lacks by default. ZAP offers a fully open codebase, community-maintained add-ons, and a mature automation framework better suited for CI/CD integration without per-seat licensing overhead.
---
ZAP operates through four primary mechanisms: interception, spidering, passive scanning, and active scanning. Each layer contributes distinct information about the target application's attack surface.
Interception and Proxy Configuration
When a user or automated process configures a browser or HTTP client to route traffic through ZAP's proxy (default address 127.0.0.1, port 8080), ZAP becomes a man-in-the-middle for all HTTP and HTTPS communication. For HTTPS, ZAP generates a dynamic TLS certificate signed by its own root certificate authority. The tester installs this CA certificate in the browser's trust store, allowing ZAP to decrypt, inspect, and re-encrypt traffic transparently. Every request and response appears in ZAP's History tab, where testers can review headers, cookies, parameters, and response bodies in full detail.
Spidering and Surface Discovery
Before scanning for vulnerabilities, ZAP must map what the application exposes. The traditional spider follows HTML links, form actions, and redirects to enumerate application endpoints. For modern JavaScript-heavy applications built as single-page applications (SPAs), the traditional spider misses dynamically rendered content. The AJAX spider addresses this by launching a real browser (via Selenium) or a headless browser, interacting with the application as a user would, and capturing all HTTP requests the application generates during that interaction. The result is a more complete site tree that includes API calls, dynamically loaded resources, and JavaScript-rendered endpoints.
Passive Scanning
As traffic flows through the proxy, ZAP's passive scanner inspects every request and response without sending any additional requests of its own. This makes passive scanning completely safe to run against production systems, because it generates no synthetic load and sends no attack payloads. Passive scan rules flag issues including missing HTTP security headers (Content-Security-Policy, X-Frame-Options, Strict-Transport-Security), cookies lacking the HttpOnly or Secure flags, information disclosure in server banners or error messages, and insecure cross-origin resource sharing (CORS) configurations. These findings require no special permissions and can be collected simply by browsing the application normally while ZAP intercepts traffic.
Active Scanning
The active scanner takes discovered endpoints and systematically sends attack payloads against every identified parameter: URL query strings, POST body fields, HTTP headers, JSON properties, and XML elements. Attack categories include SQL injection, cross-site scripting (XSS), server-side request forgery (SSRF), path traversal, remote file inclusion, command injection, and XML external entity (XXE) injection. For each parameter, ZAP sends multiple variations of known attack strings and analyzes responses for indicators of successful exploitation such as database error messages, reflected input, unexpected delays indicating blind injection, or file content in the response.
Concrete Scenario: CI/CD Integration with the Automation Framework
Consider a development team running a Node.js e-commerce application. They configure ZAP's Automation Framework using a YAML file checked into their Git repository. The YAML specifies the target URL, authentication configuration (a script that performs a form-based login and stores the session token), the scope (only URLs under the application's own domain), passive scan rules to run, active scan strength (medium), and report format (HTML and JSON). In their Jenkins pipeline, a stage after deployment to a staging environment executes the ZAP Docker container with this YAML file as input. ZAP spiders the authenticated application, runs passive and active scans, and writes a report to the build artifacts directory. A threshold rule in the YAML fails the pipeline build if any High-severity finding is detected, blocking promotion to production until the finding is remediated and the scan passes. This workflow catches introduced vulnerabilities before they reach production without requiring a dedicated security team member to run manual tests on every build.
Authentication Handling
Many real applications require authentication. ZAP handles this through authentication scripts (written in JavaScript, Python, or Groovy via the Script Console) that simulate login flows, capture session tokens, and re-authenticate automatically when sessions expire. This allows the scanner to reach authenticated application state and test endpoints that would otherwise return 401 or 302 redirects.
Add-on Ecosystem
ZAP's marketplace distributes community-developed add-ons that extend its default capabilities. Notable add-ons include the OpenAPI add-on, which imports Swagger and OpenAPI specification files to automatically seed the site tree with all documented endpoints; the GraphQL add-on, which handles introspection and scanning of GraphQL APIs; and the FuzzDB add-on, which provides curated payload lists for common attack patterns.
---
Web applications represent the most widely exploited category of internet-facing systems. The OWASP Top Ten, updated most recently in 2021, documents the most critical web application security risks including injection, broken authentication, security misconfigurations, and server-side request forgery. These vulnerabilities are consistently present in production applications across industries because the code that introduces them ships faster than the processes designed to catch it. Without a tool like ZAP embedded in development and testing workflows, organizations rely on annual penetration tests at best, leaving newly introduced vulnerabilities in production for months at a time.
Business Impact
A web application vulnerability that allows SQL injection can expose an entire customer database. A persistent XSS vulnerability in an authenticated user interface can allow an attacker to hijack administrative sessions. Path traversal vulnerabilities can expose configuration files containing credentials. Each of these outcomes carries regulatory and financial consequences under frameworks including GDPR, PCI DSS, and HIPAA, where demonstrated failure to test applications before deploying them is evidence of inadequate security controls.
Real-World Consequence
The 2017 Equifax breach, which exposed personal data of approximately 147 million individuals, resulted from an unpatched Apache Struts vulnerability (CVE-2017-5638) in an internet-facing web application. The vulnerability was a known remote code execution flaw with public exploit code available. A properly configured DAST tool scanning the application at the time of vulnerability discovery would have flagged the server-side request behavior consistent with the exploit class. While patch management and DAST scanning are separate disciplines, the incident illustrates the cost of treating web application security testing as optional or infrequent.
Common Misconceptions
A common misconception is that ZAP produces definitive results. ZAP, like all DAST tools, produces findings that require validation. False positives occur, particularly with active scan results that flag behavior that only resembles a vulnerability pattern. Equally important: ZAP can only test what it can reach and authenticate to. An application with complex multi-step workflows or non-standard authentication mechanisms may be partially tested at best unless the tester invests time in configuring authentication scripts and manually navigating workflows while ZAP records them. ZAP is not a substitute for manual penetration testing; it is a complement that raises the baseline and reduces the volume of low-hanging-fruit findings that consume manual testing time.
---
CDA approaches web application security through the Vulnerability Surface Domain (VSD) of the Planetary Defense Model. The operative methodology is Continuous Surface Reduction (CSR), expressed as a single operational directive: every surface you expose is a surface we eliminate.
In the context of web applications, this means CDA does not treat scanning as a periodic audit activity. ZAP is deployed as a pipeline component, not a scheduled event. Every deployment to a staging environment triggers a ZAP scan with a defined scope and a defined pass/fail threshold. The CI/CD configuration does not grant a pipeline stage the authority to skip the scan because the release is urgent. That constraint is intentional: urgency is the condition most likely to introduce unreviewed code into production, and it is therefore the condition where scanning is most necessary, not least.
CDA maintains a versioned library of ZAP Automation Framework YAML configurations specific to application architecture types: REST API applications, server-rendered web applications, SPA applications with JavaScript frameworks, and GraphQL API applications. Each configuration specifies authentication handling appropriate to the application, scan scope rules that prevent testing of third-party domains embedded in the application, passive scan rule sets aligned to applicable compliance frameworks (PCI DSS 6.3.2, for instance, requires periodic scanning of public-facing applications), and active scan strength calibrated to the testing environment's tolerance for synthetic load.
CDA also treats ZAP findings as inputs to the broader CSR process rather than standalone defects to close. When ZAP identifies a missing Content-Security-Policy header, the remediation is not simply adding the header; the CDA workflow traces the absence to the infrastructure-as-code template or application framework configuration that should have set it by default, and modifies that template so the class of misconfiguration cannot recur in new deployments.
The distinction between CDA's approach and a standard ZAP deployment is operational discipline: ZAP is a tool, and a tool used inconsistently provides inconsistent protection. CDA's CSR methodology transforms ZAP from an ad-hoc scanner into a continuous enforcement mechanism for application security policy.
---
---
---