OWASP ZAP

Core is one versioned program: the command line, the control API, the active-scan engine, and the alert and context models. Almost everything else — the local proxy, the passive-scan engine, the crawlers, automation, reports — ships as separately versioned add-ons.

A list in ZAP's core repository names every add-on folded into a main release, pinning each by download URL and SHA-256 hash; entries flagged core are the smaller core distribution. Container images then freeze that set at image-build time.

Lifetime, not the interface. Both switches turn the window off and both bring up the local listener. -cmd runs the registered work inline and then shuts down; -daemon runs it on a background thread and loops.

An httpsender script implements two entry points, sendingRequest and responseReceived, each handed the message, an initiator naming which part of ZAP caused it, and a send helper. It sits on the sending path every component uses.

Pull the default tag unless you know you do not need what it carries. The bare tag is a JRE-on-Alpine image with bash and curl added: no browser, no X server, no Python, and one architecture.

-certpubdump writes ZAP's root CA certificate; -certfulldump writes that same certificate and then appends its private key. A browser needs the first. The second contains a secret, because the appended key is what signs certificates.

A full, case-insensitive match against the URL with everything from the first question mark onward removed. A prefix will not match because the pattern must describe the whole string, and a rule written against a query parameter can never fire.

Both become include regexes on the context, but by different routes. Each urls entry is checked as a URI and then gets a wildcard appended; each includePaths entry is added exactly as written, so a bare URL there matches only itself.

Contexts decide it, and nothing else does. A URL is in scope when some context with its in-scope flag set includes it and no in-scope context excludes it. Exclusion crosses context boundaries, and scope has no storage of its own.

The network add-on provides it. Its LocalServer class binds the configured address and port, and ExtensionNetwork registers the -host and -port arguments. Core keeps deprecated proxy classes plus four live listener interfaces so older add-ons still compile.

Core registers five authentication method types: manual, http, form, json and script. The authhelper add-on adds browser-based, client-script-based and auto-detect logins. A plan may name all eight, but the last three fail unless that add-on is installed.

A context's verification method matches a logged-in or logged-out regex against traffic. Its strategy decides which traffic: the request, the response, both, or — the default — a separate poll request sent to a URL you nominate on a cadence you set.

Read the two recorded authentication messages and compare the login request that was actually sent against a real browser login. The login step reports only preparation and send failures, so a rejected login leaves no error behind.

Re-login is triggered only when the verification method returns a negative verdict, so a silent drop means verification kept saying yes. Read the five stats.auth.state. counters: four of them return authenticated and only one of those rests on a real match.

A context's authentication block says how to log in: the method plus its parameters, such as the login request URL and body. The users list says who logs in, each entry carrying a name and a username and password.

A definition lists every operation whether or not anything links to it, and the openapi add-on sends a real request for each one. A link-following crawl can only enqueue what a response already points at.

ZAP's spiderAjax add-on drives a browser with a bundled Crawljax but only watches HTTP traffic on a proxy it starts itself. The client add-on's spiderClient adds a ZAP browser extension that reads the DOM, so it finds content spiderAjax cannot.

It mines it. With parseRobotsTxt on, the spider seeds /robots.txt at the host root, then reads Disallow and Allow lines through the same code path and queues each path as a new target. It never obeys them.

The document decides: every server entry it declares becomes a base URL, falling back to the authority the definition came from. The job's targetUrl parameter overrides that; without it, a multi-server document is contacted at every server.

The -j flag adds a browser-driven crawl on top of the traditional spider. It now runs the client spider by default, and --ajax-spider switches back to the AJAX spider. The wrappers' own usage text still claims the opposite default.

ZAP's active-scan engine ships in core, in org.parosproxy.paros.core.scanner. The rules that craft the payloads ship separately, as scan-rule add-ons. A build with no rule add-ons still has a working scheduler with almost nothing to run.

A ZAP passive scan rule implements the core PassiveScanner interface, which hands it a recorded HTTP message and that message's history id. The interface declares no send method, so a rule can only read traffic already captured.

ZAP's pscan add-on runs a PassiveScanController that walks the History table by record id rather than the live wire. For each record it queues a PassiveScanTask, which re-reads the message and runs every enabled passive rule.

AttackStrength sets how hard a rule tries: how many payloads and requests it spends per parameter. AlertThreshold sets how much evidence it demands before raising anything. They are separate dials, and only the threshold has an OFF value.

By default a ZAP active scan may change query-string parameters, post-data parameters and a plain request body. Cookies, HTTP headers and URL path segments are left alone: TARGET_INJECTABLE_DEFAULT omits them, and no scan policy can add them.

Risk is how damaging the finding would be if it is real. Confidence is how sure the scan rule is that it is real. They are two separate fields on the alert, set independently.

The ruleId is compared for equality against the alert's scan-rule id and against its alertRef. The url, parameter, attack and evidence clauses are exact strings unless their own regex flag is set, and methods is a set. Any clause you omit matches everything.

They are job-level keys, siblings of parameters rather than entries inside it. Omit any one and the report includes everything that key could filter: every risk, every confidence band, every section the template declares.

A global alert filter is tested against every alert and is stored in the add-on's own options, so it survives the next session. A context filter applies only inside its named context and is saved with that context.

The template's own directory name under ZAP's reports folder - its id, not the display title written inside template.yaml and not the output file name. Leave it empty and the job uses risk-confidence-html.

zap-baseline.py exits 1 if a rule marked FAIL alerted, 2 if only WARN-bucket rules did, 0 if at least one rule ran and raised nothing, and 3 for everything else. -I removes only the exit-2 branch.

Format first, then component, request type and name. JSON is the response format, core the component, view the request type, version the call. The request types are view, action, other and pconn.

It is a per-rule verdict file: each tab-separated line pins one numeric scan-rule id to IGNORE, INFO, WARN or FAIL, with an optional note. Any rule the file omits defaults to WARN.

A ZAP automation plan is a YAML file with two parts: env, which names the environment the run acts on, and jobs, an ordered list of units of work. Jobs run top to bottom, in the order written.

zap-baseline.py crawls the target and passively inspects the traffic, never attacking. zap-full-scan.py adds an active scan with all rules enabled. zap-api-scan.py never crawls: it imports an API definition and attacks only what the import reached.

ZAP performs no ownership or authorisation check on a target — nothing in it resolves who owns a host. It ships only a permission warning on rendered screens such as its welcome text and Quick Start panel.

The automatable surface is where the project invests: a core -daemon option that runs it headless, one control API, and client libraries generated from that API — so an add-on's own API reaches the clients without anyone hand-writing a binding.

Control.Mode takes safe, protect, standard or attack, and is persisted under the key view.mode with standard as its default. A headless run gets standard — unrestricted — because nothing ZAP ships for automation ever sets it.

Protect mode checks only the start nodes of a scan, once, when the scan is asked to start. Over the API the refusal is MODE_VIOLATION. Nothing re-checks the mode afterwards, so it bounds admission rather than traffic.

Apache-2.0 with no paid tier settles price and access: nothing to buy, no seat to provision per CI runner, the same build everywhere. It does not settle legal review, because the shipped package bundles code under several other licences.