skip to content

Which input vectors should an unattended ZAP scan enable in CI, and what do you accept it misses?

level: principalimportance: should knowfreq 38%

answer

  1. not a quality dial
  2. three costs, not one
  3. the wider set is a different run
  4. an unenabled vector is an unasked question

basics

~20 s

Treat it as a scoped decision, not a dial. Keep the shipped set for pipeline runs; enable cookies and headers only where the target owner agreed and the session survives it; record the enabled set beside every verdict.

solid answer

~50 s

The default set — query string, post data, plain body — is the right standing configuration for an unattended run, because it is the set least likely to destroy the session the run depends on. Cookies and headers are where real findings hide and also where a scan does the most collateral damage: attacking a session cookie can invalidate the session mid-run, after which later requests test a logged-out application while reporting nothing. My rule is that the wider set belongs to a longer, owner-agreed run against a dedicated environment, expressed as a separate plan rather than a flag on the standard one. Whichever you choose, the `inputVectors` block belongs in the plan under review, and the enabled set belongs in the report — a vector you never enabled is an unasked question, not a clean answer.

go deeper

for a junior

Know that enabling more input vectors is not free: it sends more traffic and can break the session the scan depends on.

for a middle

Explain the cost of each vector concretely, and why header scanning needs its all-requests flag before it touches parameterless pages.

for a senior

Design the split: a fast standing run on the default set, a wider scheduled run on a disposable environment, and session verification behind the cookie vector.

for a principal

Own the policy across teams: what is standard, who may widen it against which targets, how the choice is recorded, and how a clean verdict is phrased so nobody over-reads it.

## State the decision properly "Should we turn everything on?" is the wrong question, because the vector set is not a quality dial. Each vector changes three things at once: what can be found, how much traffic is sent, and how likely the run is to break its own session. A defensible standard answers all three, per environment, and writes the answer down. ## What each extra vector buys and costs | vector | what it can find | what it costs | |---|---|---| | query string, post data, plain body | the bulk of injection-shaped defects | the baseline; this is what the shipped default covers | | `cookieData` | defects reachable only through a session or preference cookie | modifying a session cookie can log the run out, after which every later request tests an unauthenticated application | | `httpHeaders` | header-reflected and header-parsed defects | multiplies requests per page by the header count; needs `allRequests` before it touches pages with no parameters | | `urlPath` | defects in path segments used as values | every segment of every node becomes a parameter, so request volume climbs with the site's depth | | `scripts` | whatever your own variant script offers | only as reviewable as the script | ## The shape I would standardise 1. **The pipeline run keeps the shipped vector set** and is judged on wall-clock time and a stable verdict. Its job is to catch regressions on every change, not to be exhaustive. 2. **A wider run is a separate plan** with `cookieData` and `httpHeaders` enabled, scheduled rather than per-commit, pointed at an environment whose data and session state are disposable. 3. **The path vector is enabled per application**, not globally, and only where the routing really does carry values in segments — which is also exactly where declaring data-driven nodes pays off, since the default set already attacks those. ## Why cookies deserve the caution they get The failure is quiet, and it is worth being able to describe. A rule handed a session cookie sends a modified copy of the request; the application rejects the session; subsequent requests in the run carry a session the application has invalidated. Nothing errors. The scan continues, requesting pages that now render a login screen, finding nothing in them, and reporting a clean result for a surface it never authenticated to. The controls are session verification, a dedicated environment, and not enabling the vector by default on a shared one. ## The authorisation half of the decision This tree's subject is a program that attacks a running system, so widening the vector set is not a private tuning choice. - More vectors means **more traffic, differently shaped**, against a host someone permitted you to test on a stated basis. - A run that mutates cookies and headers can change stored state that other people's tests depend on, in an environment shared with them. - The permission you hold is usually specific. If it is, a change in what you attack is a change to be agreed, not assumed, and the plan file is the artefact to agree on. ## Verify the set, do not assume it Decisions like this rot quietly, so build in a check rather than trusting the plan file: - **Read the option back.** The injectable mask is exposed as an `ascan` option view on the control API, so a run can assert the set it is about to use rather than the set someone intended. - **Remember what overwrites what.** Any `activeScan-config` job rebuilds the vector set from the shipped defaults, so a startup config key layered under a plan is not a reliable way to widen or narrow it. - **Pin the add-on set.** An installed add-on can register a variant that no plan key gates, so the image is part of the answer to "what did this scan attack". ## What the report has to carry - **The enabled vector set, beside the verdict.** Without it, "no findings" is unfalsifiable. - **Which vectors were deliberately left off, and why.** A documented gap is a decision; an undocumented one is mistaken for coverage the next time someone reads the report. - **The plan and the add-on set together**, because an installed add-on can add a vector the plan never mentions. ## The sentence to hand a pipeline owner *The scan tests the parts of the request we told it it may change.* Everything else about the result follows from that, including what a clean run does and does not entitle anyone to say.

  • A team wants cookie scanning on every pipeline run. What do you ask for first?
    A dedicated environment and evidence that the session survives, or is re-established, when a cookie is modified. Without that the run silently degrades into scanning a logged-out application, which is worse than not enabling the vector, because it still reports clean.
  • How do you keep the vector set from drifting apart across many pipelines?
    Keep the `inputVectors` block in a plan that is reviewed and versioned like code, pin the add-on set in the image so an install cannot add a vector silently, and have the report print the enabled set so a drifted pipeline is visible in its own output.
  • Does enabling more vectors make the scan slower in proportion?
    Worse than proportional in practice, because every enabled parameter-based rule loops every variant and every parameter it offers. If you have set per-rule or per-scan duration limits — both are unlimited by default — the extra work is what makes the run hit them, and a truncated run reports what it reached, not what it skipped.

saying these in an interview costs you the question

  • Argues every vector should be enabled for maximum coverage
  • Ignores that cookie attacks can invalidate the run's own session
  • Treats the vector set as a tuning detail rather than a coverage claim
  • Widens what is attacked without the target owner agreeing
  • Reports no findings without recording which vectors were enabled