OWASP ZAP Tutorial for Beginners

This OWASP ZAP tutorial is a practical start for QA engineers and junior security-minded testers who need a free tool that can intercept HTTP traffic, explore web apps, and find common security issues. OWASP ZAP (Zed Attack Proxy) sits between your browser and the application so you can see requests, map the site, and scan for problems such as missing security headers, reflected XSS symptoms, and weak cookie flags. You do not need a commercial license to learn the workflow that professional teams use every week.

In this guide you will install ZAP, configure a browser proxy, spider and actively scan a safe target, interpret alerts, automate a baseline scan for CI, and map findings to practical QA work. You will also see how ZAP compares with Burp Suite, where beginners go wrong, and how to practice without putting real systems at risk. Pair this tutorial with security testing for QA and the OWASP Top 10 for testers so tool skills stay tied to real risk.

Practice only on systems you are authorized to test. Prefer local labs, DVWA-style containers, and company staging. Never point aggressive active scans at production without written approval.

What Is OWASP ZAP?

OWASP ZAP is an open source web application security testing platform maintained under the OWASP foundation. It is both:

• An intercepting proxy that captures browser or API client traffic.
• A scanner and automation platform that can crawl, attack, report, and run in CI.
• A manual testing workstation with request editors, history, and script hooks.

ZAP is popular because it is free, scriptable, and good enough for many QA security checks. It is not magic. A scan without context still produces noise. A proxy without HTTP literacy still confuses beginners. The goal of this OWASP ZAP tutorial is competent use, not button mashing.

What ZAP Is Good At

• Teaching HTTP and HTTPS request structure.
• Passive scanning while you explore the app like a normal user.
• Automated baseline and full scans in staging.
• API imports via OpenAPI or HAR for modern backends.
• CI gates that catch regressions in headers, cookies, and common issues.
• Free labs for people who cannot afford commercial scanners.

What ZAP Is Not

• A replacement for understanding authentication, authorization, and business logic.
• A free pass to test any website on the internet.
• A complete substitute for specialized pentesting, threat modeling, or secure code review.
• A tool that always ranks findings correctly without human triage.

If you already use a Burp Suite tutorial path at work, ZAP still matters. Many teams run ZAP in pipelines even when humans use Burp for deep manual testing.

Install OWASP ZAP

You can install ZAP as a desktop app or run it as a Docker container. Beginners usually start with the desktop app, then add Docker for CI.

Desktop Install

1. Download the official installer for macOS, Windows, or Linux from the ZAP project site.
2. Install with default options for first use.
3. Launch ZAP and choose No, I do not want to persist this session for disposable practice, or Yes if you want history saved.
4. Keep the HUD optional at first. Many beginners find the heads-up display noisy until they understand the main UI.

Docker Quick Start

Docker is useful when you want a clean scan environment:

docker pull ghcr.io/zaproxy/zaproxy:stable
docker run -u zap -p 8080:8080 -i ghcr.io/zaproxy/zaproxy:stable zap.sh -daemon -host 0.0.0.0 -port 8080

For one-shot baseline scans against a URL, the packaged baseline image or Automation Framework jobs are simpler than long-lived daemons. We cover that later.

First-Run Checklist

• Confirm Java requirements if your package needs them.
• Note the default proxy port (often 8080).
• Decide whether you will use ZAP's own browser or an external browser.
• Create a lab target before configuring real project apps.

ZAP Proxy Setup for QA

The proxy is the heart of ZAP. Once browser traffic flows through ZAP, history, passive alerts, and manual replay all become available.

Step 1: Start the Local Proxy

In ZAP, open Tools > Options > Network > Local Servers/Proxies and confirm:

• Address: 127.0.0.1
• Port: 8080 (or another free port)

Leave ZAP running.

Step 2: Point a Browser at ZAP

You can:

• Use ZAP's browser launch feature (simplest for first day).
• Or configure Chrome/Firefox to use HTTP proxy 127.0.0.1:8080.

If you configure a system browser, keep a second browser profile that is not proxied for normal browsing. You do not want personal banking or mail traffic mixed into a security lab.

Step 3: Trust the ZAP CA Certificate for HTTPS

Without the certificate, HTTPS sites fail or stay opaque.

1. In ZAP, export the Root CA certificate from network options.
2. Import and trust it in your browser or OS keychain for development use only.
3. Visit an HTTPS lab app and confirm decrypted requests appear in ZAP History.

If HTTPS still fails, common causes are wrong proxy settings, missing cert trust, or browser HSTS quirks on real sites. Labs are easier first.

Step 4: Browse the Target

Turn Intercept off while learning. Browse as a normal user:

1. Open login, register, search, profile, and checkout-like pages.
2. Watch History fill with GET and POST requests.
3. Click a request and inspect method, path, query, headers, cookies, and body.

You are already doing useful security-minded QA: seeing what the app actually sends.

Core ZAP UI Areas Beginners Should Learn

Area	What it does	When QA uses it
History	Chronological request list	Reconstruct a flow after a bug
Sites tree	Hierarchical map of hosts and paths	Understand attack surface
Intercept	Pause and edit live requests	Change role IDs, tokens, or params safely in labs
Requester / Manual Request Editor	Replay and mutate requests	Authorization and parameter tests
Alerts	Findings from passive/active rules	Triage security issues
Spider / AJAX Spider	Discover URLs and forms	Expand coverage before scans
Active Scan	Attack-like probes	Staging vulnerability checks
Automation / API	Scripted jobs and CI	Regression security gates

You do not need every panel on day one. Master History, Sites, Alerts, and one replay tool first.

Passive Scanning While You Explore

Passive scanning inspects traffic you already generated. It does not send extra attack traffic beyond what your browsing creates. That makes it a safer first habit.

Typical passive findings:

• Missing Content-Security-Policy or other security headers.
• Cookies without Secure or HttpOnly flags.
• Mixed content warnings.
• Information disclosure in server headers or error pages.
• Forms submitted over insecure schemes in misconfigured labs.

How to practice:

1. Log in and complete a main user journey.
2. Open Alerts.
3. Sort by risk (High, Medium, Low, Informational).
4. Open one alert and read the evidence URL, parameter, and description.
5. Reproduce the issue manually if the claim is high impact.

Passive scanning pairs well with functional testing. While you verify a feature works, ZAP quietly reviews transport and response hygiene.

Spider and AJAX Spider

Spidering discovers pages and parameters so later scans are not blind.

Traditional Spider

Good for multi-page apps with normal links and forms.

1. Right-click the target site in the Sites tree.
2. Choose Attack > Spider.
3. Set scope if needed.
4. Review newly discovered URLs.

AJAX Spider

Better for modern single-page applications that load content via JavaScript.

1. Right-click the site.
2. Choose Attack > AJAX Spider.
3. Provide credentials or session context if required.
4. Expect longer run times and more dynamic URLs.

Mapping Tips for QA

• Seed the spider by manually walking critical flows first.
• Import OpenAPI specs for pure API backends when available.
• Exclude logout URLs so the spider does not destroy your session mid-crawl.
• Exclude destructive admin actions from automated exploration.

A spider without authentication only maps the unauthenticated surface. That can still be valuable, but it is incomplete for member-only apps.

Active Scanning (Use Carefully)

Active scanning sends many requests designed to provoke vulnerabilities. It can create users, flood logs, or stress fragile environments. Use it only where allowed.

Safe Active Scan Workflow

1. Confirm written permission and environment.
2. Restrict Scope to the target host.
3. Authenticate and spider first.
4. Start with a small context or specific URL branch, not the entire internet-facing estate.
5. Run active scan.
6. Triage alerts with evidence before filing bugs.

What Active Scan May Find

• Reflected XSS candidates.
• SQL injection symptoms (see also how to test for SQL injection).
• Path traversal indicators.
• Remote file include style issues in older stacks.
• Some misconfigurations and insecure redirects.

What Active Scan Often Misses

• Business logic abuse.
• Multi-step authorization flaws that need two accounts.
• Complex IDOR chains that require domain knowledge.
• Race conditions and workflow bypasses.
• Issues that need mobile clients or non-HTTP channels.

ZAP is a multiplier for method, not a replacement for method.

Authentication and Sessions in ZAP

Most real apps require login. Beginners often scan only the public marketing site and then wonder why nothing important appears.

Practical Options

1. Manual login through the proxied browser, then include authenticated history in scope.
2. Form-based authentication configuration in a Context.
3. Scripted authentication for nonstandard flows.
4. Header-based tokens for API-heavy apps (paste Bearer token carefully into session properties).

Contexts

A ZAP Context groups:

• Included and excluded URL regexes.
• Authentication method.
• Users and credentials for labs.
• Session management and technology notes.

Create one Context per app environment, for example shop-staging. Keep production out unless explicitly approved.

Session Maintenance Checklist

• Exclude /logout.
• Verify authenticated pages still return 200 after spider starts.
• Re-auth if scans run long enough for session expiry.
• Never commit real production passwords into automation YAML in public repos.

Interpreting Alerts Like a Tester

Raw alert count is a vanity metric. Teams care about verified risk.

For each High or Medium alert:

1. Read the evidence: URL, parameter, attack string, response snippet.
2. Reproduce manually with Requester or browser.
3. Check false positives: scanners guess; testers confirm.
4. Assess impact: data exposure, account takeover, privilege change, availability.
5. Write a real bug report with steps, expected secure behavior, and evidence.
6. Map to OWASP category when useful for prioritization.

Example triage notes:

Alert: Cookie No HttpOnly Flag
URL: https://staging.example.com/login
Evidence: Set-Cookie: session=... without HttpOnly
Impact: If XSS exists, script can steal session cookie
Next checks: Confirm XSS surfaces; ask engineering for HttpOnly + Secure + SameSite
Priority: Medium until XSS risk clarified

Link findings to product risk language stakeholders understand. "Missing HttpOnly" is technical. "Session theft becomes easier if any XSS lands" is clearer for priority talks.

ZAP for API Testing

Modern QA often needs API security checks more than classic page crawls.

Import Paths

• OpenAPI / Swagger definition.
• HAR file from browser DevTools.
• Proxy traffic from Postman if Postman is configured to use the ZAP proxy.

API Checks QA Can Drive with ZAP

• Missing auth on sensitive endpoints.
• Verb tampering (GET vs DELETE expectations).
• Parameter pollution and unexpected fields.
• Error messages that leak stack traces.
• Insecure transport or token placement in query strings.

ZAP will not replace dedicated API functional suites, but it strengthens security-minded coverage around those suites. For functional API skill building, keep using your normal API testing habits alongside this OWASP ZAP tutorial.

Automating ZAP: Baseline Scan and CI

Automation is where ZAP often beats heavier manual-only tools for QA teams.

Baseline Scan Idea

A baseline scan is intentionally conservative. It spiders and passively analyzes (and can do light checks) to catch obvious regressions without the full weight of a deep active audit every commit.

Conceptual Docker-style baseline command shape:

docker run --rm -v $(pwd):/zap/wrk/:rw \
  ghcr.io/zaproxy/zaproxy:stable \
  zap-baseline.py -t https://staging.example.com \
  -r zap-report.html

Adjust image tags and flags to your org standards. Start with report-only mode.

CI Policy That Teams Actually Keep

Stage	Policy	Why
First month	Generate report, never fail build	Teach triage without fear
Next	Fail on new High findings only	Block serious regressions
Mature	Fail on High + selected Medium rules	Raise the bar with context
Always	Exclude known accepted risks with tickets	Avoid alert fatigue

Automation Framework

ZAP's Automation Framework uses YAML jobs for spider, passive scan, active scan, and report steps. That is the sustainable path once ad hoc CLI experiments work.

Minimal mental model:

env:
  contexts:
    - name: staging-app
      urls:
        - https://staging.example.com
jobs:
  - type: spider
  - type: passiveScan-wait
  - type: report

Expand with auth and active scan only when staging can tolerate it.

What to Store in the Repo

• Automation YAML (without secrets).
• Alert filter rules for accepted risks with ticket IDs.
• Report publishing steps for HTML/JSON.
• A short runbook for false positive handling.

Mapping ZAP Work to OWASP Risks

Tools find symptoms. Testers map them to risks and tests.

ZAP activity	Related risk theme	QA follow-up
Passive header alerts	Security misconfiguration	Add release checklist item
Cookie flag alerts	Session weakness	Verify logout, expiry, fixation cases
XSS alerts	Injection	Manual confirm + output encoding checks
Auth-related scan noise	Broken authentication	Pair with dedicated auth test cases
Access anomalies in history	Broken access control	Two-role manual tests
Stack traces in responses	Security misconfiguration / info leak	Error handling cases

For category depth, read OWASP Top 10 explained for testers. ZAP becomes more valuable when each finding feeds a regression case, not only a one-time ticket.

OWASP ZAP Tutorial Workflow: End-to-End Lab

Use this as your first complete practice loop on an authorized lab app.

Lab Goals

• Capture login traffic.
• Identify at least three passive issues.
• Spider the authenticated area carefully.
• Run a limited active scan on one form endpoint.
• File two high quality findings with evidence.
• Export a report.

Step-by-Step

1. Start ZAP desktop and create a named session lab-day1.
2. Launch the proxied browser.
3. Open the lab URL and confirm History populates.
4. Register or log in with lab credentials.
5. Walk the main features for ten minutes like a curious user.
6. Review Alerts and mark informational noise separately from likely defects.
7. Create a Context including only the lab host.
8. Spider with logout excluded.
9. Active scan one interesting branch, for example /search or /profile/edit.
10. Manually replay the most serious alert.
11. Write findings with steps and screenshots or request/response pairs.
12. Generate an HTML report for your notes.

This loop trains both tool mechanics and tester judgment.

ZAP vs Burp Suite for QA

Dimension	OWASP ZAP	Burp Suite
Cost	Free open source	Community free; Pro paid
CI automation	Strong free story	Possible, Pro features differ
Learning curve	Moderate, UI dense	Moderate, excellent manual workflow
Manual deep dive	Good	Excellent, industry standard for many pentesters
QA team default	Great for scans + free training	Great for daily request surgery
Best combined use	Pipeline and baseline gates	Human investigation and exploit proof

Many mature teams use both: ZAP for automated gates, Burp for hands-on validation. Choosing one tool forever is less important than learning HTTP, auth, and triage.

Writing Bugs from ZAP Findings

A weak bug:

ZAP says XSS on search. Please fix.

A strong bug:

Title: Reflected XSS in search query parameter q on staging
Environment: staging.example.com, build 2026.07.08
Steps:
1. Log in as standard user.
2. Open /search?q=<script>alert(1)</script>
3. Observe script execution / unencoded reflection in response body line 214.
Expected: Query is encoded/escaped; script does not execute.
Actual: Payload reflects unencoded; browser executes script in lab.
Impact: Session theft and UI redress risk for users who open crafted links.
Evidence: ZAP alert ID, request/response, screenshot.
Regression idea: Add encoded output case to security suite.

Security bugs still need clear expected results, just like functional defects. See the broader mindset in security testing for QA.

Common Mistakes with OWASP ZAP

Mistake 1: Active Scanning Production

This can create data corruption, lockouts, or legal trouble. Keep aggressive modes in labs and approved staging.

Mistake 2: Scanning Without Scope

ZAP can follow offsite links. Restrict included hosts so you do not accidentally probe third parties.

Mistake 3: Ignoring Authentication

Unauthenticated scans of a mostly private app produce a false sense of safety.

Mistake 4: Filing Every Alert Blindly

Alert spam destroys trust with engineering. Verify, prioritize, and batch informational items.

Mistake 5: Treating ZAP as the Whole Security Program

You still need secure design review, dependency management, secrets hygiene, and authorization testing with two roles.

Mistake 6: No Regression After Fixes

If a header was missing and then fixed, add a check so it cannot silently disappear next release. Automation baseline jobs shine here.

Mistake 7: Mixing Personal Browsing with the Proxy

Keep a clean lab browser profile. It protects privacy and reduces noise in History.

Mistake 8: Stopping at Tool Certificates Pain

HTTPS setup frustrates beginners. Budget time for cert trust. Without it, you only half-learn ZAP.

Practical QA Checklist Using ZAP

Use this checklist on each major release candidate in staging:

• Proxy captures login and main purchase or core flow.
• Passive alerts reviewed for new High/Medium items.
• Security headers present on primary responses.
• Session cookies use Secure and HttpOnly where applicable.
• Logout invalidates session on replayed request.
• OpenAPI or spider coverage includes authenticated routes.
• Baseline automation job published report for the build.
• Previously fixed ZAP findings still fixed.
• Any accepted risks linked to tickets with owners.
• Destructive admin routes excluded from automated active scans.

How Far Should QA Go with ZAP?

A healthy division of labor:

QA owns

• Proxy literacy for debugging.
• Baseline scans in CI.
• Verification of security bug fixes.
• AuthZ smoke checks with request replay.
• Header and cookie regression awareness.

Security specialists own

• Deep exploitation and red team objectives.
• Complex threat models.
• Production-adjacent controlled tests with formal rules of engagement.
• Org-wide scanner policy and exception governance.

When those lanes are clear, ZAP becomes a bridge rather than a turf war.

Learning Path After This OWASP ZAP Tutorial

1. Complete two full lab sessions with notes.
2. Reproduce one XSS or injection style finding manually.
3. Configure a Context with authentication on a demo app.
4. Add a baseline scan to a personal CI project.
5. Read OWASP Top 10 categories and map five alerts to categories.
6. Practice writing two security bug reports a week from lab work.
7. Compare one workflow in both ZAP and Burp to build tool flexibility.

For hands-on QA practice beyond tools, train product thinking in QABattle battles and then ask, "What would ZAP see if this flow were real and misconfigured?"

Final Workflow You Can Reuse at Work

When a feature is security sensitive:

1. Define scope and environment permission.
2. Capture the happy path through ZAP proxy.
3. Note new endpoints and parameters in Sites/History.
4. Review passive alerts introduced by the change.
5. Add targeted manual request tests for auth and input.
6. Run spider and limited active scan if staging policy allows.
7. Triage, verify, and file quality defects.
8. Add CI baseline coverage for stable checks.
9. Retest fixes with the same evidence path.
10. Keep accepted risks visible, not forgotten.

The point of this OWASP ZAP tutorial is not to turn every QA engineer into a full-time penetration tester overnight. The point is to make web risk visible, discussable, and regression-proof. Once you can install ZAP, proxy a browser, read History, spider carefully, scan safely, and turn alerts into verified bugs, you have a durable security testing skill that compounds with every release.

If you remember one rule, remember this: ZAP multiplies good testing judgment. It cannot replace it. Use the tool inside clear scope, verify every important alert, and convert fixed issues into automated memory so the same hole does not reopen next quarter.