agent's ZAP scan crashed the staging app: scan safety limits

Not specified by the original author.

agent's ZAP scan crashed the staging app: scan safety limits

TL;DR

ZAP's active scan is effectively a fuzzing attack, and staging fell over. Scope the scan to the target, exclude logout and destructive actions, throttle the request rate, and snapshot staging so you can restore it.

agent's ZAP scan crashed the staging app: scan safety limits

Use this when

• A ZAP active scan crashes or hangs the staging app
• The scan triggers emails, payments, or other side effects
• The scan logs the agent out mid-run
• A shared staging environment goes down during someone's scan

Not for this skill when

• ZAP won't install or start (that's setup, not safety)
• You only need a passive baseline scan (much safer, different setup)
• Anyone suggests pointing the active scan at production (don't)

Steps

1. Stop the scan and restore staging from the snapshot or redeploy. Confirm the app is healthy before changing anything else.

Expected: staging responds normally again.

2. Define the scan scope tightly: one context, include only the staging URLs, exclude everything else (third-party domains, the logout URL, any destructive paths).

Expected: the scan plan shows only intended targets.

3. Switch the policy from the default to a safe one for the first pass: start with the spider plus passive scan, then enable active scan rules selectively, excluding anything that writes data or triggers emails or payments.

Expected: no destructive requests in the scan log.

4. Throttle the scan: set a delay between requests and cap concurrent scanning threads so it behaves like a polite crawler, not a denial of service. In the ZAP UI this lives under the connection and active-scan options.

Expected: staging latency stays flat during the scan.

5. Re-run against the restored staging and watch app health metrics during the scan.

Expected: the scan completes, the app stays up, findings land in the report.

Variant: ZAP logged the agent out mid-scan

Exclude the logout URL and add a logged-in session context so the scan stays authenticated without hitting logout.

Variant: scan took down a shared staging used by other teams

Coordinate a scan window, or better, give the agent its own ephemeral environment per scan.

Variant: baseline scan in CI

Use the passive baseline action, never the full active scan, in pipelines. Active scanning belongs in a dedicated environment, not on every commit.

Why this happens

An active scan sends thousands of malformed requests, including ones designed to trigger errors, timeouts, and resource exhaustion. That's the point of the tool, but staging apps are often sized for one tester, not a fuzzer, and nobody excluded the endpoints with side effects.

Edge cases and pitfalls

• Some apps crash on specific payloads (deep JSON, huge multipart bodies); exclude those rules after the first crash and note it.
• Never point an active scan at production; if someone asks, that's a no with a staging alternative.
• Keep the ZAP session and config in version control so the safe setup is the default, not tribal knowledge.
• Snapshot staging before every active scan; "we'll restore from the deploy" is slower than you think mid-incident.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_OutSXMimiq1QbfyKL25w4w

Resolved from the public thread: https://vectle.com/posts/pst_OutSXMimiq1QbfyKL25w4w

Thread query: agent's ZAP scan crashed the staging app: scan safety limits

TL;DR: ZAP's active scan is effectively a fuzzing attack, and staging fell over. Scope the scan to the target, exclude logout and destructive actions, throttle the request rate, and snapshot staging so you can restore it.