When a request matches ZAP's proxy exclude list, does it still reach the target host?

## The answer, and the mechanism behind it Yes, it still reaches the host. Exclusion on ZAP's proxy path is a **marking** operation, not a blocking one, and the code makes that explicit. The `network` add-on's local-server handler is where a proxied message is first classified. It computes whether the message is excluded — testing the request URI against the global exclusion regexes and against the session's exclude-from-proxy list — and then records the verdict on the handling context. It does not return early, and it does not close the connection. It calls on into the handler pipeline exactly as it would for any other message. What the verdict then changes is which handlers *look* at the message: - Handlers written as "interested only in non-excluded messages" — an abstract base whose `handleMessage` runs its subclass only when the context is not marked excluded — skip it. The request and response handler bases are both built on it, so everything hanging off them is silently bypassed. - **The sender handler is not built on it.** It is the final handler in the proxy pipeline, and it sends the message regardless. For an excluded message it sends with a request configuration built with listener notification switched off, then marks the context overridden so the rest of the pipeline is short-circuited. The response is still written back to the client. From the browser's point of view nothing happened at all. ## What exclusion actually buys you | you might assume | what actually happens | |---|---| | the request is dropped | it is sent, by the final handler in the pipeline | | the host never hears from you | the host receives it and answers | | nothing is recorded | correct — listener notification is off, so it does not reach the history-driven machinery | | passive rules will not see it | correct, and for the same reason | | it is a containment boundary | it is a noise filter | So the feature is real and useful. It keeps a logout endpoint, a third-party analytics beacon or a chatty polling URL out of your history, out of the passive engine's queue and out of your report. It does exactly none of the thing its name suggests to a reader worried about *where traffic goes*. Note the scope of the claim. This is the **proxy** path — the global exclusion regexes and the session's exclude-from-proxy list, as consulted by the local-server handler. Other exclusion lists are read by the components that own them and can genuinely stop those components choosing a URL as a target. The dangerous case is the proxy path, because that is what people reach for when they mean "do not touch that". ## Why this is the most consequential sentence on this subject Everything else in ZAP's scope machinery is at least a decision about behaviour. This is a decision about bookkeeping that reads, in a configuration file, exactly like a decision about behaviour. The failure it produces is therefore quiet: 1. Someone decides a host or a path must not be touched during a run. 2. They add it to an exclusion list, because that is the control whose name matches the intent. 3. The run proceeds. The excluded URLs are absent from the history, absent from the report and absent from every count. 4. The traffic went out anyway. The only record that would have shown it is the record that was suppressed. The evidence and the event are removed by the same switch. That is worth saying plainly in an interview, because it is the reason this is not a trivia question: **the control that fails here also removes the trace of its own failure.** ## What to do instead - **Do not express a must-not-touch boundary as a proxy exclusion regex.** Express it as a target the run is never given, or as a boundary outside the process — the runner's own egress. A boundary the scanner enforces is a boundary a misconfiguration can remove. - **Use exclusion for what it is good at**: keeping known-noisy or destructive-if-recorded URLs out of the working set, so the report is about what you meant to test. - **Be careful what you promise about it.** "We excluded that host" is a statement about your report, not about your traffic, and it is worth saying which you mean when someone asks whether a host was touched. - **Separate it in your head from the mode.** A mode can refuse to start a scan. A proxy exclusion cannot refuse anything; it only changes who is told.