In the previous module we closed out SAMM by noting that several improvements in BazarNube's roadmap (the Security Testing and Secure Build practices) can't stand on strategy alone: they demand running real security tests against the running application. That "what do we use to do it?" has a concrete name in the open-source world: OWASP ZAP. With this lesson we move from strategy (Top Ten, ASVS, SAMM) to the tool that lets us confirm and discover vulnerabilities dynamically, while the app runs in staging. In this first chapter you'll understand what ZAP is, how it's built under the hood, and what role it plays within BazarNube's assurance workflow.

1. What ZAP is and where it comes from
2. ZAP as an intercepting proxy and as a DAST tool
3. Architecture and key components
4. Passive scanning versus active scanning
5. ZAP's modes (safe, protected, standard, attack)
6. Common use cases
7. How ZAP fits into the BazarNube workflow
8. Ethical and legal note

ZAP stands for Zed Attack Proxy. It's a free, open-source tool for finding security vulnerabilities in web applications and APIs while they run. By a wide margin, it's the most widely used free dynamic scanner (DAST) in the world.

A note on its governance, because it causes confusion:

• It was born and grew for years as an OWASP flagship project.
• In 2023 the project moved to the Software Security Project (SSP) foundation, where its development continues. That's why you'll find documentation calling it "OWASP ZAP" and more recent documentation calling it simply "ZAP".
• For BazarNube's practical purposes the organizational umbrella doesn't matter: the tool, the binary, and the community are the same. In this course we'll call it ZAP.

Remember what we saw in M2: ZAP is DAST (Dynamic Application Security Testing). It tests the running application, from the outside, the way an attacker would, without needing to see the source code. It's complementary to SAST (which analyzes static code) and SCA (which analyzes dependencies). They don't compete: they combine.

ZAP has two sides that are worth keeping separate:

The key point is that everything goes through the proxy. ZAP doesn't guess the app's structure: it learns from the requests that pass through it. The better it "sees" your traffic (manual browsing + spiders), the better its results will be.

Under the hood, ZAP is a set of pieces that work together. Knowing them helps you interpret the GUI and, later on, automate.

• Intercepting proxy: the heart of it. It captures all HTTP(S) traffic. It lets you pause requests (breakpoints) and edit them before sending.
• Sites tree: the hierarchical map of everything ZAP has seen of BazarNube (domains, paths, endpoints, parameters). It's the source the scanners operate on.
• Traditional Spider: crawls the app by following links in the HTML. Fast, but it gets lost with JavaScript-generated content.
• AJAX Spider: drives a real (headless) browser to crawl single-page applications (SPAs). Essential for BazarNube's React frontend, where many routes don't exist until the JS generates them.
• Passive scanner: observes traffic that has already passed through the proxy and detects problems without sending anything new (missing security headers, cookies without flags, information leaks). It's safe by nature.
• Active scanner: injects payloads (SQLi, XSS, path traversal...) against the discovered parameters and observes the response. It's intrusive.
• Alerts: each finding, classified by risk (High/Medium/Low/Informational) and confidence.
• Add-ons (Marketplace): ZAP is modular; almost all advanced functionality (AJAX Spider, scan rules, report formats, the Automation Framework) arrives as updatable add-ons.

This distinction is the most important one in the whole lesson, because it marks what is safe to run and what isn't.

Mental rule for BazarNube: you can keep the passive scanner on all the time; the active one is fired only against your own staging and with the team's knowledge.

ZAP has a global switch that limits what it can do. It's your safety net so you don't accidentally attack something you shouldn't.

Tip: when starting out with BazarNube, work in Protected mode with a well-defined scope (we'll cover this in 06-02). That way, even if the spider discovers an external link (for example a third-party payment gateway), ZAP won't attack it.

• Assisted manual exploration: you browse BazarNube with the proxy on and ZAP passively detects problems while you use the site.
• Automated scanning of a URL or an API (with its OpenAPI/Swagger definition).
• API testing: you import the OpenAPI spec of the Node/Express backend and ZAP knows every endpoint without needing to spider.
• Security regression in CI/CD: every deploy fires a baseline scan (we'll cover this in 06-04).
• Confirming specific findings: a pentester reported an IDOR; you use ZAP to reproduce it in a controlled way.

Remember the thread of the course. In M3 the Top Ten gave us concrete findings in BazarNube: an IDOR in /api/orders/{id}, SQLi in a search feature, XSS in product reviews, missing security headers, a legacy Java endpoint at risk of XXE, and an import function that looked like SSRF. In M4 we turned part of that into verifiable ASVS requirements. In M5 SAMM told us organizationally that we needed to do Security Testing.

ZAP is the piece that closes the loop: it takes those theoretical findings and verifies them dynamically on BazarNube's staging.

Lucía (backend) wants to confirm whether the search SQLi is still alive after a patch. Marc (frontend) wants to know whether the review XSS fires with the new sanitizer. The SRE wants all of this to run on its own on every deploy to staging. ZAP answers all three.

ZAP sends real attacks. The active scanner injects SQL injections, XSS, and more against the target application. This has serious implications:

• You may only actively scan systems you own or for which you have explicit written permission.
• With BazarNube we always work against our own staging environment, never against production or against third-party infrastructure (payment gateways, CDNs, external APIs).
• An active scan can corrupt data, trigger emails, exhaust resources, or take down the service. Treat it as a destructive test.
• Scanning a system that isn't yours without authorization can constitute a crime in most jurisdictions.

This warning will recur throughout the module. It isn't a formality: it's the line that separates professional AppSec from unauthorized access.

• Believing "ZAP finds vulnerabilities on its own": ZAP only tests what it has seen pass through its proxy. If you don't explore the app well (manual + spiders), large areas go unanalyzed.
• Running an active scan "to see what comes up" with no scope: you end up attacking third-party domains. Always define the scope and work in Protected mode.
• Thinking the passive scanner is enough: passive doesn't find SQLi or XSS; for that you need the active one. Both are complementary.
• Forgetting the AJAX Spider on SPAs: with a React frontend like BazarNube's, the traditional spider barely sees anything. You need the AJAX Spider.
• Tip: always start by understanding the traffic as a proxy before automating. If you don't understand what requests BazarNube makes, you won't interpret the alerts correctly.

Exercise 1. Classify each finding by whether ZAP's passive or active scanner would detect it: (a) BazarNube's session cookie lacks the HttpOnly flag; (b) the search feature is vulnerable to SQLi; (c) the Content-Security-Policy header is missing; (d) a redirect parameter allows open redirection.

Exercise 2. The team is going to test BazarNube on staging but fears ZAP might accidentally touch the external payment gateway pay.tercero.com, which appears linked from the checkout. Which ZAP mode would you choose and what must you configure to prevent it?

Exercise 3. Marc asks why the traditional spider found almost no routes in BazarNube's seller panel, which is a React SPA. Explain the cause and the solution within ZAP.

Solution 1. (a) Passive: it's detected by observing the Set-Cookie header without sending anything new. (b) Active: it requires injecting payloads and observing the response. (c) Passive: it's the absence of a header in responses already seen. (d) Active: you have to try malicious values in the redirect parameter.

Solution 2. Choose Protected mode, which only allows intrusive actions against URLs within the scope. Define the scope to include only BazarNube's staging domain and exclude (or simply not include) pay.tercero.com. That way, even if the spider discovers the link, ZAP won't fire attacks against it.

Solution 3. The traditional spider only follows links present in the initial HTML. In a React SPA, the routes and links are generated dynamically with JavaScript after load, so there are barely any static links to follow. The solution is to use the AJAX Spider, which drives a real browser capable of executing the JS and discovering the generated routes.

You now have the mental map of ZAP: an intercepting proxy that also acts as a DAST scanner, with clearly differentiated pieces (sites tree, spiders, passive and active scanners, alerts) and a set of modes that bound how much damage it can do. You've seen the critical distinction between passive (observe, safe) and active (attack, only on your own staging) and how ZAP closes the loop we opened with the Top Ten, ASVS, and SAMM over BazarNube.

In the next lesson, 06-02 Installation and Configuration, we move from theory to having ZAP up and running: we'll install it (package and Docker), configure the browser and the root certificate to inspect HTTPS, and prepare the context, scope, and authentication needed to test BazarNube's authenticated areas.