Evaluate a DAST tool by pointing it at a staging copy of your own app, behind a real login, and measuring what it reaches, what it finds and how long a scan takes. A tool that cannot stay logged in or understand your API will report on your login page and little else.
Why does authentication decide the trial?
Dynamic testing sends requests to a running application. Most of your risk sits behind a login, in account pages, admin screens and API calls. The ZAP documentation reflects this: it points to an authentication decision tree as the place to start if you need the scanner to authenticate to your app. Authentication is a first-class problem, not an add-on.
So make it the first test. Give the tool a test account, and check whether it stays logged in through the scan, handles session expiry, and copes with your login method, whether form login, single sign-on, tokens or multi-factor prompts for a test user. Many failures hide here: the scan finishes quickly and clean because it never got in.
How do you measure coverage?
Ask the tool to report what it visited. Compare the list with the pages and API routes you know exist.
- Crawl coverage. How many routes did it find in a single page application, where links are built by scripts?
- API coverage. Can you import an OpenAPI description so the tool knows endpoints that no page links to?
- State handling. Can it follow multi-step flows such as checkout or onboarding?
The OWASP Web Security Testing Guide is a flagship OWASP resource for testing web applications, with version 4.2 available and 5.0 in development. Use it as a checklist of vulnerability classes to confirm the tool exercises, rather than trusting a vendor's claim of "full coverage."
How do you judge findings?
Plant two or three known weaknesses in staging if your policy allows, for example a missing authorization check on one endpoint, and see whether the tool notices. Then sample findings and classify them as real, informational or false. Check whether each finding includes the request and response that proves it, since evidence lets a developer reproduce it in minutes.
Remember the limit: DAST sees behavior from outside. It will miss flaws that need source knowledge and many business logic problems. Pair it with code analysis rather than treating one as a substitute.
What about safety and fit?
Scan staging, never production first. Check scope controls so the tool cannot wander to third-party domains. Check rate limiting so it does not take your test environment down. Ask how it avoids destructive actions such as deleting data through a discovered delete endpoint.
For delivery, test automation: can a scan start from CI, run within your time budget, and report in a form your team already reads? The ZAP docs list automation as its own area, which is the kind of capability to expect from any serious tool.
What to do
- Prepare a staging environment with realistic data and test accounts, one per role.
- Run an authenticated scan first and confirm the session holds.
- Import your API description and compare routes visited with routes that exist.
- Plant a small number of known weaknesses and record detection.
- Sample findings and label them real, informational or false.
- Check each finding has request and response evidence.
- Test scope and rate limits so the scan stays on your assets and does not break staging.
- Run it from CI and time it against your pipeline budget.
- Compare tools using the same app, accounts and labels.
Try a scan walkthrough
Our DAST demo shows what a web app scan looks like from start to finish.
Open the full demo at /demos/dast-web-app-scan.
Quick check
Why did my DAST scan finish with almost no findings?
Often the scanner never got past the login page. Check the crawl report for authenticated routes before you trust a clean result.
Should I run a trial scan against production?
Not at first. Use a staging copy with test data, scope limits and rate limits, so a scan cannot corrupt data or overload a live service.
Sources
- ZAP documentation, fetched 18 October 2026.
- OWASP Web Security Testing Guide, fetched 18 October 2026.
The trial steps are practical suggestions from this guide.
Last reviewed: 18 October 2026.
