In ZAP, how would you standardise authenticated-scan verification across services without the polling itself distorting results?

## What is actually being standardised Every context that scans an authenticated target carries the same four decisions: whether an indicator pattern is mandatory, which verification strategy is used, what the poll endpoint may be, and what evidence the pipeline must produce before the result counts. Left to individual teams, those decisions get made once per service, badly, by whoever first got a scan to go green. Standardising them is worth doing because **all four failure modes are silent** — a scan configured wrongly here does not fail, it just stops seeing anything. ## Decision one: an indicator is mandatory With no indicator pattern configured, the check returns *authenticated* before it looks at anything. Re-authentication can then never be triggered, so the session obtained at the start is the only one the run will have. This is the single highest-value rule to impose, and it is enforceable by reading the plan rather than the run. Specify the marker's quality too, not just its presence. The match is a **search** over the header and body, so a marker that appears in persistent site furniture or a bundled script will confirm a session that has already died. The house rule should be *a string the application cannot render for an anonymous visitor*. ## Decision two: strategy, and what each one costs | strategy | traffic added | what it judges | where it fails | |---|---|---|---| | per-request | none | text the tool wrote itself | weakest signal; the target has not spoken | | per-response | none | whatever the crawl happened to fetch | asset and error responses are poor evidence | | both | none | all four message parts | inherits both weaknesses | | poll | one request per cadence | a response you chose | the poll reaches the target and carries the session | | auto-detect | none | nothing directly — deferred to an add-on | an add-on dependency, and no verdict from core | The honest comparison is not *cheap versus expensive*. It is **incidental evidence versus chosen evidence**. A per-response strategy is free, and it judges the session from whichever page the crawler reached — which may be a static asset, a redirect, or an error page. A poll costs a request and judges the session from a page you picked precisely because its answer is unambiguous. ## Decision three: the poll endpoint is a real request This is the part that is easy to get wrong and hard to notice. The poll is built as an ordinary message, marked as belonging to the user so the session-management method stamps the session onto it, sent through the same sender under the same rate limiting as scan traffic, and recorded in history with a verification tag. So: - It is **visible to the target**: its access logs, its rate limits, its own analytics. - It **exercises the session**, which means an endpoint that slides a session expiry forward on access will keep the scanner's session alive indefinitely. The scan then cannot experience the expiry that a real client would, and any behaviour that depends on that expiry goes untested. - It runs at a cadence you chose, so on a long scan the poll traffic is not negligible against a rate-limited target. The standard should therefore name the *shape* of an acceptable poll endpoint: cheap, read-only, unambiguous in its logged-in and logged-out renderings, and — where the application offers the choice — one that does not extend the session. ## Decision four: what the pipeline asserts 1. **Assert on the authentication-state counters, not the report.** A run whose no-indicator count is non-zero was not checking. A run with a large assumed-in count and a non-zero logged-out count was losing the session repeatedly inside windows where nothing was checked. 2. **Compare crawl surfaces.** An authenticated run that discovered the same URL set as an anonymous run never carried the session at all — a session-management defect, not a verification one, and the counters will not distinguish them for you. 3. **Treat a login-success count far above one as a signal**, not as noise. It means the session kept dying. ## Where the standard should stop Resist making the cadence a single global number. The right window depends on the target's own session lifetime and on how fast a given scan sends, and those differ per service. Standardise the **unit** — so that the window is expressed in scan volume rather than wall-clock time where that matters — the mandatory indicator, the acceptable endpoint shape, and the evidence. Leave the value to the team that knows how long their sessions live.