We closed the previous lesson (07-03) with an idea: Burp Professional is excellent, but it carries a paid license and is not always the best choice when what you want is to integrate web testing into automated pipelines. For that terrain there is a free, complete alternative maintained by the community: OWASP ZAP (Zed Attack Proxy). It is Burp's natural companion in the web pentester's toolkit, and in the TechNova audit it would be the tool you use to leave a scan running or the one you wire into the pipeline of the store tienda.technova.lab.

This lesson covers ZAP's architecture, the key difference between passive and active scanning, the traditional spider and the AJAX Spider for modern applications, the automatic vs. manual modes, the HUD (Heads-Up Display) over the browser, and, most distinctively, its automation and API for CI/CD and DevSecOps. We close with a Burp vs. ZAP comparison table so you know when to use each. We do not repeat the theory of web vulnerabilities (Module 4): here it is about operating the tool and understanding how it fits into pipelines. As always, everything is done against authorized targets or your lab.

1. What OWASP ZAP is and why it matters
2. Architecture and working modes
3. Passive vs. active scanning
4. Spider and AJAX Spider
5. The HUD: testing from the browser
6. Automation and API for CI/CD
7. Comparison table: Burp vs. ZAP
8. Common Mistakes and Tips
9. Exercises
10. Conclusion

OWASP ZAP is an open-source and free web intercepting proxy, the flagship project of the Open Web Application Security Project (now under the Software Security Project). It shares Burp's central idea (sitting between the browser and the server) but with two differences that define its character:

• It is free and complete: it includes automatic active scanning at no cost, something that in Burp is reserved for the Pro edition.
• It is built to be automated: it offers an API and utilities designed to run without a graphical interface, inside continuous integration pipelines.

That makes it the go-to option for DevSecOps: dropping a web security test into every deployment, unattended and for free.

ZAP is organized around the same proxy scheme, with a set of its own components.

ZAP offers security policy modes that limit what it can do, a safeguard designed precisely to avoid attacking something out of scope by mistake:

The Protected mode is the best practice: it guarantees that active scanning only hits what you have declared as the authorized target, avoiding the classic accident of scanning a third-party domain.

This is ZAP's most important distinction and the one you must always keep clear.

• Passive scanning is always running in the background: while you browse the TechNova store, ZAP analyzes each response and raises alerts (for example, missing security headers, exactly one of the findings from Module 6) without touching anything.
• Active scanning is intrusive: it launches payloads against the discovered parameters to trigger and confirm vulnerabilities. It is powerful but dangerous in production, because it can insert garbage data, trigger actions, or take down the service.

Responsible use: passive scanning is safe in almost any context; active scanning is only launched against authorized targets or your lab, and with impact under control. Against tienda.technova.lab on your host-only network you can scan actively without fear because the server is yours.

Before scanning you have to discover the application's URLs. ZAP ships with two crawlers:

• Traditional spider: follows HTML links recursively. Fast and enough for classic server-rendered sites, such as a traditional PHP store.
• AJAX Spider: controls a real browser to run JavaScript and discover content that only appears after interaction. Essential in modern applications (SPAs with React, Angular, Vue) where the classic spider sees almost nothing because the content is generated on the client.

For TechNova's PHP store, the traditional spider covers almost everything; the AJAX Spider would come into play if the store had a cart or a search box built with dynamic JavaScript.

The HUD (Heads-Up Display) is a distinctive ZAP feature: it overlays its controls directly on the web page in the browser, without having to switch to the ZAP window. You see alerts, launch the spider or active scan, and review findings from icons in the margins of the web page itself.

• Advantage: a very visual flow, ideal for learning, because it links each alert to what you see on screen.
• When: manual, interactive work. For automation you use headless mode and the API (next section).

It is enabled from the ZAP toolbar ("Enable HUD") and by opening the proxied browser. It is one of the reasons ZAP is highly recommended for those starting out in web testing.

Here is ZAP's big differentiator against Burp. ZAP can run without a graphical interface (headless) and be controlled via REST API or scripts, which lets you drop a web security test inside a deployment pipeline. It is the basis of DevSecOps: automated security in every release.

A common use is the baseline scan (mostly passive) packaged in Docker, ideal for a CI/CD pipeline:

• zap-baseline.py browses and runs the passive scan, generating a report.
• -t indicates the (authorized) target; -r the HTML report file.
• It returns a nonzero exit code if it finds alerts, which lets you fail the build when security problems appear.

That exit code is the key to fitting into CI/CD: the pipeline can automatically block an insecure deployment. For more thorough scans there is zap-full-scan.py (includes active scanning, only against authorized environments). And to orchestrate everything declaratively, ZAP offers the Automation Framework (YAML plans) and the API for custom integrations.

Responsible use: even in CI/CD, the scan target must be an environment that is yours (staging, lab), never a third party. Automating does not remove the need for authorization.

Both do the essentials (proxy, spider, manual replay, scanning). Choosing depends on the context.

Rule of thumb:

• Choose Burp for deep manual pentesting, especially if you have the Pro edition: Repeater and Intruder are the standard for interactive work.
• Choose ZAP when the budget is zero, when you need free active scanning, or when you want to automate in CI/CD and DevSecOps.
• In practice, many professionals use both: Burp for the engagement's manual work and ZAP for automation and unattended scans. They are not mutually exclusive rivals; they are complementary.

• Launching an active scan without authorization. Active scanning sends real payloads and can damage data or the service. Use it only against your lab or authorized targets; for everything else, stay passive.
• Confusing spider and scan. The spider discovers URLs; the scanner tests them. Without a prior spider (or AJAX Spider), the scan does not see half the application.
• Forgetting the AJAX Spider in SPAs. On JavaScript-heavy sites, the traditional spider discovers almost no content. Use the AJAX Spider.
• Not using Protected mode in engagements. Without it, an active scan could hit an out-of-scope domain. Restrict actions to the scope.
• Automating against third parties. Putting ZAP in CI/CD does not exempt you from authorization: always point at staging or your own lab.
• Tip: start with the passive scan and the HUD to learn without risk, and make the jump to active scanning and automation when you have the impact under control.

Exercise 1. Explain in your own words the difference between ZAP's passive and active scanning, with an example of what each would detect in the TechNova store, and say which one you can launch without authorization and why.

Exercise 2. You want to integrate a web security test into the deployment pipeline of the TechNova store (your own staging environment). Write the zap-baseline.py command with Docker and explain how you would make the build fail if alerts appear.

Exercise 3. A team is torn between Burp and ZAP. Scenario A is a week-long deep manual pentest; scenario B is adding automatic security to every deployment with zero budget. Recommend a tool for each scenario and justify it.

Solution 1. The passive scan only observes the traffic I generate by browsing, without sending attacks: it would detect, for example, the absence of security headers or cookies without the Secure flag in the store. The active scan sends payloads against the parameters to trigger vulnerabilities: it would detect a SQL injection in producto.php?id= by launching quotes and statements. I can launch the passive scan without authorization because it does not touch the server (it only watches); the active scan requires explicit authorization or my own lab, because it is intrusive and can alter data or degrade the service.

Solution 2.

zap-baseline.py returns a nonzero exit code when it finds alerts. In the pipeline, it is enough not to ignore that code: if the CI step fails (exit code ≠ 0), the build is marked as failed and the deployment is blocked. This way a web app with security problems never reaches production. The target is your own staging, not a third party.

Solution 3. Scenario A (deep manual pentest): Burp Suite, preferably Pro. Repeater and Intruder are the standard for the interactive, meticulous work of a week-long engagement. Scenario B (automatic security, zero budget): OWASP ZAP, because it is free, includes free active scanning, and is designed to run headless with an API and in Docker inside a CI/CD pipeline. Many teams, in fact, use both: Burp for the manual work and ZAP for the automated part.

OWASP ZAP is the free and complete alternative to Burp, and it shines exactly where Burp charges or falls short: free active scanning and, above all, automation in CI/CD and DevSecOps. We reviewed its architecture and its security modes (with Protected as best practice), the crucial distinction between passive scanning (observes, safe) and active scanning (attacks, requires authorization), the spider and the AJAX Spider for discovering classic and modern applications, the HUD for learning visually, and its API/headless mode for dropping security into every deployment with zap-baseline.py and failing the build on alerts. The comparison table made the rule clear: Burp for deep manual pentesting, ZAP for the free and the automated, and in practice both at once.

With ZAP we complete the web tooling and, with it, the in-depth tour of the four great tools in the toolkit: Kali as the environment, Metasploit for exploitation, and Burp and ZAP for the web. You now know what a pentester works with. There remains the most important question of all: how to keep growing in this profession legally and ethically. The course's final lesson answers that: Continuous Learning Resources.