In OWASP ZAP, where can a URL be excluded, and which part of a run does each place affect?

## Three places, not one "Exclude this URL" is not one setting in OWASP ZAP. It is three, they are stored in different places, they are read by different components, and only one of them is part of a context. ### 1. A context's exclude list Regexes held by the `Context` object itself, written as `excludePaths` in a plan or added from the site tree. They subtract from **scope**, and therefore from everything that derives from scope: a crawl bound to that context, the passive engine when it is restricted to in-scope traffic, and the active scanner's scope check. They are matched with the query string already removed. ### 2. The session's per-subsystem URL lists Core's session holds several lists of regexes keyed by a type constant in its URL table. Each is read by exactly one kind of consumer: - **exclude from proxy** — read by the `network` add-on's local server handler as traffic passes. - **exclude from scan** — merged into the exclude list that core's active-scan engine is given. - **exclude from spider** — merged into the exclude list handed to the traditional crawler, and to both browser-driven crawlers. - **exclude from websocket** — read by the `websocket` add-on. These are *not* context settings. They belong to the session, they apply whatever context a job names, and they are ordinarily set from the desktop window or over the control API. ### 3. Global exclusions, in the `network` add-on A separate list again, owned by the add-on's `GlobalExclusionsOptions`. Core has no implementation of its own: `Session.getGlobalExcludeURLRegexs()` calls a supplier, and **returns an empty list when no supplier has been installed**, which is the case in any build without that add-on. The list is also not saved in the session. It is read in three places: the proxy handler, the crawler's fetch filter, and the active scanner's exclude list. The shipped defaults are worth knowing about because they are easy to misread. The add-on ships a prepared set — media and document extensions, stylesheets and scripts, and a handful of well-known third-party hosts — and **every one of them is shipped disabled except the Windows-Update entry**, which ships enabled. Only enabled entries are returned to callers. ## Which one each consumer actually reads | consumer | context excludes | session list | global exclusions | |---|---|---|---| | local proxy handler (`network` add-on) | no | exclude-from-proxy | yes | | traditional and browser crawlers (`spider`, `spiderAjax`, `client`) | yes, via the context it is bound to | exclude-from-spider | yes | | active-scan engine (core `Scanner`) | yes, via the scope check | exclude-from-scan | yes | | passive engine (`pscan` add-on) | yes, via scope, when restricted to it | no | no | Read the table by column and the shape becomes clear: the **context** layer is the one every scanning component consults once a context is bound to the job, and the **global** layer is the only one that reaches the proxy as well as the scanners. ## What a plan can and cannot express This is where a pipeline reader is most often caught out. - A context's `excludePaths` is expressible in a plan, in the `env.contexts` block. - Of the session lists, **only exclude-from-scan is reachable from a plan**, through the `activeScan-config` job — whose key for it is also called `excludePaths`. Two keys, the same name, the same help text in the shipped template, two entirely different layers. - **No job sets global exclusions.** They are an add-on option: a configuration key, or the desktop window. A plan cannot turn one on. And one sharp edge on the job that can write a session list: it writes it **unconditionally**. Its data object holds an empty list when the key is absent, and running the job replaces whatever the session held. Against a fresh one-shot run that is invisible, because the list was empty anyway; against a long-lived daemon, or a saved session loaded with `-session`, adding an `activeScan-config` job with no `excludePaths` key **clears the exclusions that were already there**. ## How to choose 1. If the rule should govern what the run treats as its target, put it in the **context**. It is the only layer that travels inside a plan and the only one every scanning component consults. 2. If the rule must keep a specific endpoint away from the active scanner only, the session exclude-from-scan list is the right layer, and `activeScan-config` is how a plan reaches it. 3. If the rule is about noise on the wire — third-party hosts, static assets — that is the **global** layer, and you are accepting that it needs an add-on, cannot be written in the plan, and will be silently absent in a build that does not carry that add-on.