Short answer: prove you own the target before any active test runs, restrict every request to an allow-listed scope, keep the tests non-destructive and rate limited, and read the results per host instead of per page. Safeguard DAST works this way and offers broad first-party DAST coverage of web applications and APIs.
Why teams hesitate
Dynamic testing has a reputation for two failures. The first is breakage: a scanner sends enough traffic or the wrong payload and takes a staging system down, or worse. The second is scope: the scanner follows a link to a host the team does not own and tests it. Both are serious, and both are reasons teams skip DAST altogether and find the flaw in production instead.
A third problem shows up afterwards. A scan of a large site can produce thousands of repeated rows for the same missing header, which buries the few findings that matter.
The steps
- Register the target and its scope. Write down the exact hosts and paths that are in scope. Anything not on the list is out.
- Prove ownership. Verify the target with a DNS TXT record, a token file at a well-known path, a meta tag, or an address on the target's domain. Until verification succeeds, treat the target as off limits for active checks.
- Pick a safety mode. Start passive, which only observes. Move to safe active, which sends bounded, non-destructive probes, once you are comfortable. Use an authenticated safe active scan, with a test account, to reach what sits behind a login.
- Use a test account, not a real user. Credentials sign the scan's requests. Use an account created for testing, and make sure the scanner removes tokens and keys from findings and reports.
- Set limits. Per-target rate limits, a maximum duration and benign detection markers keep the load predictable. Avoid any tool that offers destructive or denial-of-service payloads as a default.
- Handle private addresses properly. A hosted scanner cannot reach localhost or private ranges. Run a scanner inside your network for those.
- Read the results per host. A missing security header is a host-level issue. It should appear once for the host, not once per page. Injection and parameter findings should stay one per path and parameter, because two different injection points are two different problems.
- Check coverage, not only findings. Ask what the scan did not reach. A partial scan, for example one that lost its login session, should say so.
- Link runtime findings to source. When a runtime issue maps to the source code that produced it, fix it once at the cause.
A short checklist before the first scan
- The target is verified and the scope list is written down.
- You chose passive or safe active deliberately, and you know which one you chose.
- A test account exists, with the least access that still reaches the pages you care about.
- Someone who can restart the target knows the scan window.
- You know where the results go: a findings queue, a ticket, a chat alert.
What Safeguard does
Safeguard keeps a target unverified until you prove ownership, and active checks cannot run on an unverified target. Every outbound request is checked against your allow-listed scope, and out-of-scope requests are blocked and logged. The controls live in the scanner, not in a screen, so the command line refuses an unverified or out-of-scope target whatever flags you pass.
Coverage is first party: Safeguard's own DAST engine tests security headers, injection classes, misconfiguration and the API surface. Host-level issues are reported once per host, and a verified-only option keeps tentative rows out of the results. If a login with an interactive code lapses mid-scan, the scan is marked partial and says so.
Download
Download the datasheet, US Letter (PDF)
Download the datasheet, A4 (PDF)
