To scan a web app for vulnerabilities, get written permission, choose a non-production copy, run a passive baseline scan first, add login and an active scan, then triage the findings and fix the confirmed ones. Dynamic scanning tests the running app from outside, the way an attacker would see it.
What a web vulnerability scan is
A dynamic scan, often called DAST, sends requests to a running application and watches the responses. It does not read your source code. That makes it good at problems that only show up at runtime, such as missing headers, exposed error messages and injectable parameters. It cannot see logic your app never exposes over HTTP.
Two modes matter. A passive scan only looks at traffic that passes through, so it is safe almost anywhere. An active scan sends attack payloads, which is why ZAP's own documentation says not to use it on applications you do not own.
Choosing a scan type
| Goal | Scan type | Risk to the target |
|---|---|---|
| Quick hygiene check | Passive baseline | Low |
| Deep test of one release | Active scan, authenticated | Medium to high |
| Scan an API from its definition | API scan | Medium |
| Ongoing checks in a pipeline | Scheduled baseline plus periodic active | Low to medium |
Steps
- Get written permission and a scope list of hostnames. Scanning systems you do not own can be illegal.
- Point the scan at staging or a disposable copy with test data, not production.
- Run a passive baseline first. ZAP's baseline script runs a spider for one minute by default, waits for passive checks and does not attack the target.
- Configure login so the scanner can reach pages behind authentication. Use a dedicated test account.
- Run an active scan with a time budget. Watch the target's error rate and stop if it degrades.
- Export the report and group findings by weakness type, not by URL.
- Verify the high severity items by hand, fix them, and rescan to confirm.
What to expect
Scanner output is a list of leads. Some are confirmed problems, some are noise. ZAP's documentation notes that active scanning cannot find logical flaws such as broken access control, so pair it with manual tests for authorization. Expect the first run to be noisy, and tune it rather than switching it off.
Common mistakes
Scanning only the login page because the crawler could not authenticate. Running an active scan against shared staging while a demo is happening. Treating a clean report as proof of safety, when it only means the scanner found nothing within its reach.
Try it yourself
Run the scan and open one finding. Look at the request, the response evidence and the suggested fix.
Click through it at your own pace, or open it full screen.
Quick check
Is it legal to scan any website?
No. Scan only systems you own or have written permission to test. Active scans send attack traffic.
Do I need to scan production?
Not for most checks. Use staging with realistic configuration. Reserve production for passive checks agreed with the owner.
Where Safeguard fits
Safeguard offers dependency and SBOM scanning, reachability analysis and policies and gates that can block a pull request, so the libraries behind your app are checked alongside the app itself. You can try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
