Ask a dynamic application security testing vendor how its scanner logs in, reads your API definitions, stays inside scope, avoids damaging a live system and reports evidence for each finding. Then trial it against your own application. A demo against the vendor's sample site tells you very little.
What does DAST do, and where does it stop?
OWASP describes this category of tools as scanners that test a running web application from the outside for issues such as cross-site scripting, SQL injection, command injection, path traversal and insecure server configuration. They find what an outside tester could reach. They do not read your source, so they cannot point to the line of code.
That is the honest limit. DAST sees behavior, not intent. It misses what it cannot reach, such as pages behind an unfinished login flow, and it can only confirm what it can trigger.
What should you ask?
Access. 1. How does it authenticate? Single page apps, OAuth, multi-step logins and session expiry break many scanners. Ask for a live test against a login like yours.
Coverage. 2. How does it discover pages and endpoints, and can it import an OpenAPI definition? Open source tools such as ZAP support OpenAPI import, so a commercial tool should be at least as capable. 3. Does it handle JavaScript-heavy front ends with a browser-based crawl?
Safety. 4. How do you restrict scope to hosts and paths you own? 5. Can you set request rate limits so a scan does not knock over a fragile service? 6. What does it do with destructive actions, like delete buttons and payment forms? Ask for the default behavior.
Evidence. 7. Does each finding include the request, the response and the reason it was flagged? 8. How does it reduce false positives, and does it confirm a finding rather than guess from a banner?
Process. 9. Can it run in the pipeline and fail a build on defined rules, with results in a standard format? 10. How are results tracked over time, so you can show a finding was fixed?
Fit. 11. Where does it run: your network, their cloud, or both? Ask what leaves your environment, which matters for regulated data. 12. What happens to scan data and credentials you give it, and for how long are they kept?
How should you run the trial?
NIST SP 800-115 treats testing as a planned activity with rules, and it recommends weighing the benefits and limits of each technique. Apply the same discipline. Pick a staging copy of a real application with test accounts. Plant two or three known issues. Score tools on whether they found the planted issues, how many extra findings were wrong, and how long a human spent sorting them.
OWASP notes that tools have different strengths and points to its Benchmark project for measuring detection. Use public benchmarks as a starting point and your own app as the judge.
What does DAST not replace?
It does not replace static analysis, dependency scanning or manual testing. Business logic flaws, such as one user reading another's order, usually need a human who understands the app. Treat DAST as one layer.
See a scoped dynamic scan in the DAST web app scan demo.
What to do
- Write a one page requirements list from the twelve questions.
- Choose a staging app with test accounts and written permission to scan it.
- Plant known issues so you can measure recall.
- Trial two or three tools with the same scope and rate limits.
- Count true findings, false findings and hours of triage.
- Check what leaves your network and what the vendor retains.
- Decide, and set a review date.
Quick check
Can DAST run against production?
Only with explicit scope, rate limits and agreement from the system owner. Most teams scan staging and keep production scans narrow.
Does a clean DAST report mean the app is secure?
No. It means the scanner found nothing it could reach and recognize. Logic flaws and unreachable areas can remain.
Sources
- OWASP: Vulnerability Scanning Tools (DAST), fetched 18 October 2026
- ZAP documentation: Active Scan, fetched 18 October 2026
- NIST SP 800-115, Technical Guide to Information Security Testing and Assessment, fetched 18 October 2026
Last reviewed: 18 October 2026.
