Does ZAP check that you are allowed to scan a target, and what does it ship instead?
answer
- the tool never asks who owns it
- a warning, not a control
- it lives in message bundles, not code paths
- welcome text, Quick Start panel, help page
- headless renders none of those screens
basics
~20 sZAP 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.
solid answer
~50 sZAP has no notion of who owns a host. There is no ownership lookup and no confirmation step; a run attacks whatever URL it is handed. You can declare a scope, and a restricted mode can refuse a scan that starts outside it, but scope is something you assert — the program cannot tell whether it matches what you were permitted to touch. What the project ships instead is a sentence — *"you should only attack applications that you have been specifically been given permission to test"* — carried by core's `api.home.topmsg` message, the `quickstart` add-on's attack panel and shipped help page, and the `plugnhack` add-on's intro text. Each of those is a rendered screen, and a `-cmd` or `-daemon` start renders none of them. The permission fact is an input that arrives from outside the tool.
go deeper
Recall the plain fact: the tool sends attack traffic at whatever URL you give it, and checks nothing about who owns that host. The permission warning is text on a screen.
Be able to say where the sentence actually lives — core's API home message, the quickstart add-on's panel and help page, the plugnhack add-on's intro — and that a headless start renders none of them.
Show that you treat the target URL as a security-relevant job input on a level with a credential, because a wrong value sends attack traffic at a stranger with no error anywhere.
Own the consequence: entitlement is a fact the tool cannot hold, so the place it is recorded and checked is an architectural decision about the pipeline, not a setting in the scanner.
## 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.
- Is the authorised-use statement part of ZAP's licence?No. It is a user-interface string in shipped message bundles. The licence and legal-notice files carry licence terms and third-party attribution; neither they nor `README.md`, `CONTRIBUTING.md` or `SECURITY.md` mention authorised use. Nothing about it is contractual, and nothing about it is checked at runtime.
- Doesn't defining a scope amount to an authorised-target list?Only in the sense that you wrote it. Scope is an assertion the operator makes, and a restricted mode will enforce it at a scan start — but the program never checks that assertion against anything. A confidently wrong scope is enforced exactly as faithfully as a correct one.
- A scan finished cleanly against the wrong host. What in ZAP would have caught that?Nothing, by itself. A run completing means the host answered. The mode setting can refuse to start a scan based on ZAP's own configuration, and proxy exclusion lists do not stop traffic at all. Neither consults ownership, so the wrong-host case has to be prevented before the tool starts.
saying these in an interview costs you the question
- Thinks ZAP refuses to scan a host you do not own
- Believes the shipped permission warning blocks or prompts anything
- Assumes any scanner validates the target before attacking it
- Says the authorised-use rule is a licence term
- Treats a declared scope as proof the target was authorised
- Expects a headless run to be more cautious than a desktop one