Your ZAP target authenticates with a bearer token rather than a cookie — which session-management method carries it?

## Why the default type fails here The core `cookie` session-management method keeps a per-user cookie jar and replays it on each outgoing request. Against an API whose session lives in an `Authorization: Bearer ...` header, that jar is empty, so the method dutifully adds nothing and every request after the login goes out anonymous. Nothing errors. The crawl simply never reaches the authenticated surface, and the run still finishes and still produces a report. That is the shape of the problem: the wrong session type is not a crash, it is a quiet reduction in coverage. ## The header type The `authhelper` add-on registers a **header-based session-management type**. Its configuration is a list of pairs: - the **first** element is a header name; - the **second** is a value **template** — a literal string that may contain `{%source:key%}` placeholders. Before each request goes out, the method walks its pairs and sets each header on the request, substituting any placeholder it finds. One pair is handled specially: a pair whose header name is `Cookie` is turned into a cookie on the request rather than a raw header, and a cookie the session store is already tracking is skipped so it is not added twice. ## Where the placeholder values come from During the login exchange the add-on records **session tokens**. A token is a triple of source, key and value, and its placeholder name is `source:key`: | source | what it reads | |---|---| | `json` | a field of a JSON login response, addressed by a dotted path | | `header` | a header of the login response | | `cookie` | a cookie set during the login | | `url` | a parameter of the authentication URL | | `script` | a global script variable | | `env` | an environment variable of the process | One detail bites people. When a recorded token comes from an `Authorization` header whose value begins with a bearer scheme, the token's stored value is the part **after** the scheme — the raw credential, with `Bearer ` removed. That is deliberate, because the same token often has to be re-emitted in a differently shaped header. It means the template must re-add the scheme itself, which is exactly what the add-on writes when it generates the configuration for you: ```yaml sessionManagement: method: headers parameters: Authorization: "Bearer {%header:authorization%}" ``` If a placeholder resolves to nothing, the substitution puts the placeholder text **back** into the header rather than emitting an empty value — a deliberate choice so that a misconfigured template shows up in the recorded request instead of disappearing. ## Ownership, and what that costs you This type is **not in core**. Core ships cookie-based, HTTP-auth and script-based session management and nothing else. Two consequences for anyone running the tool unattended: 1. A plan that names `headers` needs the `authhelper` add-on present. The automation add-on resolves the value by a hard-coded numeric type identifier, and when the add-on is missing the lookup returns nothing and the plan raises an environment error. 2. The same add-on also registers an `autodetect` type, which carries nothing itself and relies on a passive rule to observe the session tokens and then **replace** the context's method with a configured header one. That is convenient interactively and fragile unattended, because it depends on traffic having been recorded and the passive engine — a separate add-on again — having processed it. ## Choosing between them - If you know the header shape, **configure `headers` explicitly**. It is deterministic and it appears in the plan, so a reviewer can see what the scanner is sending. - Use `autodetect` to *discover* the shape on a new target, then write the result down as an explicit configuration. - Do not reach for the `script` session type first. It is the escape hatch for a scheme the header templates cannot express — a value that must be recomputed or re-signed per request, for example — and it costs you a scripting engine add-on as well. ## Checking that it worked The header method increments a counter each time it sets one of its configured headers on an outgoing request — cookie pairs take the other branch and are not counted — so on a header-only configuration, a run whose counter stays at zero is a run in which the session was never carried, whatever the report says. Pair that with the authentication-state counters, and you have a machine-readable answer to *did this scan actually run logged in*, which is a far better acceptance signal than eyeballing the findings list.