Every hands-on lesson so far has been manual: you read a page in DevTools, tampered with one request in a proxy, iterated a single parameter in a fuzzer. That precision is the heart of good testing - but it does not scale. A real application has hundreds of endpoints and a long tail of misconfigurations that are tedious to find by hand and trivial for a tool to flag.
An automated vulnerability scanner crawls an application and probes it with a library of checks, producing a list of alerts in minutes. In this lesson, the custom panel simulates an OWASP ZAP workflow and supplies NovaCart alert evidence without launching ZAP or sending traffic.
The catch, and the real subject of this lesson, is that a scanner produces alerts, not findings. Every alert is a hypothesis a human must confirm or dismiss. The professional skill is triage, not clicking Scan.
Two modes do very different things:
- Passive scanning observes traffic and flags what it can see without attacking - missing headers, insecure cookie flags, information leaks. It is safe: no load, no state change.
- Active scanning attacks the discovered requests with injected payloads (SQLi, XSS, traversal) and studies the responses. It finds far more but is intrusive and high-volume - effectively the manual payload tampering you explored through the proxy, automated and run across the whole site.
In this lesson you will:
- Explore Scan Workflow to compare spidering, passive analysis, and active scanning.
- Use ZAP Alerts and Commands → Triage to verify one simulated true positive and recognize a likely false positive.
- Name the class of flaw a scanner can never find (business logic), and report one missing security header the passive scan hands you for free.
Estimated time: 10 to 15 minutes.
Prerequisites: intercepting-proxies (request interception and replay with ZAP) and vulnerability-reporting-cvss (turning verified alerts into findings).
A word on scope first: this custom panel is fully simulated and sends no scan traffic. A real active scan is one of the loudest things a tester can do—thousands of payloaded requests that can create, modify, or delete data—so run one only against a target you are explicitly authorized to attack.
When you are ready, send the Continue signal.