Does ZAP check that you are allowed to scan a target, and what does it ship instead?

## The check that is not there A scanner is a program that sends attack traffic at whatever address it is handed. It is worth being precise about what ZAP does before it sends that traffic, because the honest answer is: nothing that concerns ownership. - There is no registry, directory or resolver lookup that asks who a host belongs to. - There is no confirmation step. A headless start runs its work and exits; nobody is asked anything. - The target is a string you pass in, and it is used as given. - You *can* declare a scope, and a restricted mode can refuse a scan that starts outside it — but scope is a thing you assert, and the program has no way to know whether what you asserted matches what you were actually permitted to touch. The add-on that comes closest to reasoning about permission is `accessControl`, and it proves the point rather than softening it: before it can test whether an application enforces its own access rules, a human must mark every node in the site tree Allowed, Denied or Unknown, per user. `Unknown` is the default. Even for the target's *internal* authorisation model the program refuses to guess — so it is no surprise that it does not guess about the boundary of your engagement either. ## What the project ships instead The boundary is stated, not enforced. ZAP carries a sentence, verbatim, in shipped English resource bundles: > "Please be aware that you should only attack applications that you have been specifically been > given permission to test." | where it lives | what surfaces it | who sees it | |---|---|---| | core, the `api.home.topmsg` message | the API's own home page in a browser | someone who opens the local API page | | the `quickstart` add-on's attack-panel message | the desktop Quick Start tab | a desktop user, before pressing Attack | | the `quickstart` add-on's shipped help page | the bundled help viewer | a desktop user who opens help | | the `plugnhack` add-on's intro text | that add-on's own panel | a desktop user of that add-on | The **absence** half of that list is as informative as the presence half. The sentence is not in the repositories' `README.md`, `CONTRIBUTING.md` or `SECURITY.md`, and it is not in the licence or legal-notice files — those carry licence terms and third-party attribution, nothing about authorised use. The authorised-use statement is a **user-interface string**, not a licence term and not a runtime condition. ## Why a pipeline never meets it Every surface in that table is rendered. A `-cmd` or `-daemon` start renders none of them: there is no Quick Start tab, no help viewer and nobody browsing the API home page while a job runs. The tool states the rule only where a pipeline never looks. That produces a specific failure shape, and it is the shape interviewers probe: 1. A job is written once, by someone who did know which host was in bounds. 2. The URL is pinned in a file, or a variable, or a job parameter. 3. Later the environment moves, the variable is edited, or the job is copied into another repository, and the host it now points at is a host nobody signed for. 4. The scan runs to completion and reports findings. Nothing anywhere refused. ## What follows for the person running the scan - **The permission fact is an input, and it has to arrive from outside the tool.** The scanner will not supply it, validate it, or remember it. - **Do not read a completed run as evidence of anything but reachability.** It finished because the host answered, not because you were entitled to ask. - **Treat the target as the security-relevant parameter of the job**, on a level with a credential — because a wrong value here sends attack traffic at a stranger, silently. - **Know which mechanisms are genuinely offence-limiting** and which only look like it. A mode setting can refuse to start a scan; exclusion lists on the proxy path do not stop traffic at all. Neither of them, and nothing else in the program, knows who owns a host. ## The register to answer in A weak answer treats the warning text as if it did something — "ZAP warns you, so you get a prompt." A strong answer names the seam: the program can refuse a *scan* on the basis of its own configuration, and it can never refuse a *target* on the basis of who owns it, because that fact does not exist anywhere inside it. Everything the tool can enforce is about its own state; everything about entitlement is carried by the people and the process around it.