You already know what ZAP is and what pieces it's made of. Now we're going to get it running and, above all, properly configured to test BazarNube. Installing ZAP is easy; the real work is in the configuration: intercepting HTTPS with the root certificate, defining a context and a scope that bound what can be touched, and setting up authentication to reach BazarNube's protected areas (seller panel, checkout, orders API). Without that preparation, ZAP will only see the public part of the store and will miss exactly where the juiciest findings live.

1. Ways to install ZAP
2. Installing with Docker
3. First steps in the GUI
4. Configuring the browser and the proxy
5. Installing the root certificate for HTTPS
6. Defining the context and the scope
7. Configuring BazarNube's authentication
8. Verifying that everything works

ZAP is distributed in several ways. Choose based on your use:

Installing on Linux from the cross-platform package:

Check that you have Java available if you use the cross-platform package:

For BazarNube we'll use Docker often, because staging already runs in containers and this way ZAP lives in the same world. Official images:

• zaproxy/zap-stable: latest stable version (the one we'll use).
• zaproxy/zap-weekly: weekly build, for very recent features.

-config api.addrs.addr.* authorizes API clients. On real networks, restrict the addresses instead of using .*. We'll go deeper into this in 06-04, when the API takes center stage.

For ZAP in Docker to reach BazarNube's staging that also runs in Docker, connect them to the same network:

When you open the GUI for the first time, ZAP asks whether you want to persist the session. For serious work on BazarNube choose "Yes, I want to persist this session": that way you keep the sites tree, alerts, and history.

Main areas of the interface:

• Sites (left): the tree of everything discovered about BazarNube.
• Request / Response (center): the detail of the selected request.
• History / Search / Alerts / Output (bottom): working tabs. Alerts is where you'll live.
• Mode bar (top left): the Safe/Protected/Standard/Attack dropdown we saw in 06-01. Set it to Protected.

ZAP listens by default as a proxy on localhost:8080. You have two paths:

Option A — Built-in browser (recommended to start). ZAP can launch a Firefox/Chrome already preconfigured with the proxy and certificate in place. In the GUI, click "Manual Explore" or "Explore your application" and Launch Browser. It's the frictionless route.

Option B — Your own browser. Point the system or browser proxy to ZAP. Example of manual proxy configuration:

With Firefox and a dedicated profile from the command line:

If you prefer an extension, FoxyProxy lets you toggle the ZAP proxy with a click.

BazarNube uses HTTPS. For ZAP to see and modify the encrypted traffic, it acts as a legitimate man-in-the-middle: it generates certificates on the fly signed by its own root CA (ZAP Root CA). Your browser must trust that CA, or you'll see certificate errors on every request.

Steps:

1. In the GUI: Tools > Options > Network > Server Certificates (in older versions, Dynamic SSL Certificates).
2. Click Save to export the root certificate to a file, e.g. zap_root_ca.cer.
3. Import it as a trusted CA in the browser or in the system.

Export the certificate from the command line (handy for automation):

Trust the CA on Linux (Debian/Ubuntu):

In Firefox: Settings > Privacy & Security > Certificates > View Certificates > Authorities > Import and tick "Trust this CA to identify websites".

Security: the private key of that CA lives in your ZAP. Anyone who has it could intercept your traffic. Don't share your ZAP root certificate or leave it installed in day-to-day browsers. Generate a new one periodically from the same panel.

A context in ZAP is a logical grouping of URLs that represent one application and its rules: which URLs belong to it (scope), how it authenticates, what users there are, what's excluded. It's the key unit for working with focus.

For BazarNube we'll create a context called BazarNube-Staging:

1. In the Sites tree, right-click on the staging domain > Include in Context > New Context.
2. Define the scope with include and exclude regular expressions.

Example scope patterns:

The /logout exclusion pattern is one of the most useful tricks: without it, the spider follows the "Log out" link, loses the authenticated session, and stops seeing the private areas.

Much of BazarNube's risk (the IDOR in /api/orders/{id}, the seller panel) is behind the login. For ZAP to test those areas, you have to teach it to authenticate and to keep the session alive.

BazarNube uses form login that returns a JWT in a session cookie. Configuration in the context:

1. Authentication method (Context > Authentication). Choose Form-based Authentication and define the login request:

2. Session indicators — how ZAP knows whether it's still authenticated:

• Logged-in indicator (regex that appears ONLY when authenticated): \"role\":\"seller\" or the text "Log out".
• Logged-out indicator (regex that appears when the session is lost): Sign in or a 401.

3. Session management (Session Management). For a JWT in a header, use HTTP Header Based Session Management, or Cookie-based if it travels in a cookie.

4. Users (Context > Users). Create staging test users (never real production credentials):

Having two users lets you test access control (can buyer_test read seller_test's orders?), which is the essence of the backlog's IDOR.

How the whole session flow fits together:

Quick check with the ZAP API (context and user already created):

Before scanning (lesson 06-03), confirm this checklist:

• [ ] ZAP starts (GUI or daemon) and the proxy listens on 8080 / the API on 8090.
• [ ] The browser routes through ZAP and no certificate errors appear on HTTPS.
• [ ] When browsing BazarNube, requests appear in History and the Sites tree grows.
• [ ] The BazarNube-Staging context exists with correct include/exclude scope.
• [ ] With Force User authenticated, ZAP accesses the seller panel without asking for a login.

Proxy smoke test with curl:

• Certificate errors on every page: you haven't imported (or trusted) the ZAP Root CA. Re-export it and import it as an authority.
• The spider logs out your session: you're missing the /logout exclusion in the scope, or you didn't configure the logged-out indicator.
• ZAP doesn't see the React frontend's traffic: the SPA's fetch/XHR may ignore the system proxy; use ZAP's built-in browser or configure the proxy in the browser itself, not just in the OS.
• Using real production credentials: never. Create test users exclusive to staging.
• Port 8080 in use: another app (or the legacy Java Tomcat) is using 8080. Change ZAP's port with -port or under Tools > Options > Network > Local Servers/Proxies.
• Tip: save the exported context (Context > Export Context) as a versioned file; you'll reuse it in the automation in 06-04.

Exercise 1. You're intercepting BazarNube over HTTPS and the browser shows "The connection is not secure" on every page. What is the most likely cause and how do you fix it?

Exercise 2. Write the include and exclude scope patterns for a context that covers https://staging.bazarnube.local, prevents the spider from logging out, and doesn't touch the external gateway pay.tercero.com.

Exercise 3. You want ZAP to test the seller panel, which requires a login. List the four elements you must configure in the context so that ZAP keeps the authenticated session.

Solution 1. The browser doesn't trust the ZAP Root CA, which signs on the fly the certificates ZAP presents. Solution: export the root certificate from Tools > Options > Network > Server Certificates, import it as a trusted authority in the browser/system, and reload. Quick alternative: use ZAP's built-in browser, which already has it configured.

Solution 2.

• Include: https://staging\.bazarnube\.local.*
• Exclude: https://staging\.bazarnube\.local/logout.*
• Exclude: .*pay\.tercero\.com.*

The patterns are regular expressions; remember to escape the dots.

Solution 3. (1) Authentication method (form-based with the URL and POST data of /api/auth/login); (2) session indicators (logged-in and logged-out) so ZAP can detect whether it's still authenticated; (3) session management (cookie or header depending on how the JWT travels); (4) at least one test user with its staging credentials.

With ZAP installed, the root certificate trusted, the proxy routing BazarNube's traffic, and a context with well-defined scope and authentication, you have the platform ready for serious work. All this preparation isn't bureaucracy: it's what lets the scanner reach the authenticated areas where the real risk lives, without straying out to attack third parties.

In the next lesson, 06-03 Vulnerability Scanning, we set the machinery in motion: we'll explore BazarNube with the spider and the AJAX Spider, let the passive scanner work, launch the active scanner with an appropriate policy, and learn to interpret the alerts, triage false positives, and generate reports that map the findings to the Top Ten and to BazarNube's backlog.