Practical documentation · Authorized use only

OWASP ZAP

OWASP ZAP is a web proxy and scanner that supports safe, staged application-security validation. Use the proxy first to understand traffic, define scope and authentication safety, then run low-impact checks against an owned or disposable target.

Web ScannerVulnerabilityProxyJava

Start safely and get useful results

Best for

• Web proxy review
• Passive and controlled active validation

Not for

• Unapproved active scanning
• Credential harvesting or destructive tests

Before you run anything

• Document the authorized target, time window, success criteria, data-handling rules, and a named stop contact before you begin.
• Confirm the installed version with the tool’s version or help command, then compare its documented behavior with the linked upstream project before relying on any option.

Practical workflows

Beginner

Use ZAP as an intercepting proxy in a local lab

Scenario: Review requests from a disposable training application.

zap.sh -daemon -host 127.0.0.1 -port 8080

Start the daemon bound locally; configure a dedicated lab browser to use the proxy.

Expected use: Expect captured requests and passive alerts; inspect context and scope before acting on alerts.

Intermediate

Run a controlled baseline scan

Scenario: A local OWASP Juice Shop lab needs a non-production security baseline.

zap-baseline.py -t http://localhost:3000 -r zap-baseline.html

Run the baseline scan only against the local training target and save a report for review.

Expected use: Alerts are triage items; validate them manually and tune false positives before reporting.

Interpret results like an analyst

• Passive alerts often identify missing headers or patterns, not exploitability.
• Use contexts and authentication definitions to avoid scanning out-of-scope links or accounts.

Common mistakes and operating tips

Avoid

• Launching an active scan before setting scope and exclusion rules.
• Treating a scanner alert as a final finding without reproduction and impact analysis.

Operational discipline

• Treat command output as evidence, not a conclusion: retain the command, version, scope, timestamp, and a redacted result in the engagement record.
• Start with the smallest safe scope, validate expected behavior in a lab or pilot, then expand only when the authorization and monitoring plan support it.

Verify against the current upstream

Tool behavior and release syntax can change. Treat this guide as practical operating context, then verify version-specific details against the upstream project before an assessment.

Open authoritative upstream documentation