DAST, or dynamic application security testing, tests a running web application from the outside by sending requests and studying the responses. It needs no source code, finds issues visible at runtime, and misses flaws that only code review or business knowledge can reveal. Below are ten direct answers, with the reasoning behind each.
1. What does DAST actually do?
OWASP's DevSecOps guidance describes DAST as black-box testing that finds weaknesses in a running application by injecting malicious payloads, aimed at flaws such as SQL injection and cross-site scripting. It works on the client and server side without needing the source code or the framework the application is built on. It usually requires little interaction once configured and can run as part of a nightly scan.
2. Does it need my source code?
No. That is the main difference from static analysis. It does need a running, reachable target, valid test accounts for anything behind a login, and a defined scope.
3. What does it find well?
| Finding type | Typical strength |
|---|---|
| Injection and reflected input | Good, with active scanning |
| Missing security headers and weak cookie flags | Good, even passive |
| Information leaks in responses and errors | Good |
| Misconfigured transport and redirects | Good |
| Weak session handling | Moderate |
4. What does it miss?
Flaws that depend on knowing your business rules. The OWASP testing guide says automated tools, DAST included, are generic: they are built for applications in general, not for your custom code and business rules, and they often lack the application-specific context needed to detect deeper flaws. It recommends balancing automated scanning with manual and semi-automated techniques. It also misses code paths the crawler never reaches, and issues inside libraries that never show at the HTTP layer.
5. How long does a scan take?
It depends on app size, scan depth, rate limits and caps. A short passive baseline can finish in minutes. The ZAP documentation says its baseline script runs the spider for one minute by default and takes a few minutes at most, while its full scan runs an active scan and can run for a long period. Plan short scans for every change and long ones on a schedule.
6. Is it safe to run in production?
Passive checks usually are, with scope controls. Active scans send attack payloads and can create data, send messages and load servers, so run them on a disposable test environment. Read the guidance on protecting test data from a scan before your first run.
7. Does it work on single-page apps and APIs?
Often, with setup. A single-page app needs a browser-driven crawler, and an API needs an imported definition or captured traffic. Without those, the scanner may see one page. Check coverage against your own route list.
8. How many false positives should I expect?
Some. Policy settings trade false positives against missed issues: ZAP's documentation says a low threshold raises more potential issues and may increase false positives, while a high one may miss real issues. Plan time to confirm findings and tune.
9. How does it fit with other testing?
| Technique | Looks at | Needs |
|---|---|---|
| DAST | Running app from outside | A test environment |
| Static analysis | Source code | Repository access |
| Software composition analysis | Libraries and their versions | A manifest or build output |
| Manual review and penetration testing | Logic, design, chained flaws | Skilled people and time |
They overlap a little and complement a lot. No single one covers everything.
10. What should I ask in a trial?
- Can it log in to my app and prove it stayed logged in?
- Does its crawl reach my single-page routes?
- Can I import my API definition?
- Can I save and version scan policies?
- Can I see coverage, not just a count of alerts?
- How are credentials and stored traffic handled?
- Can I export results in an open format?
Score the answers on your own app, in a copy of your staging environment. Trying a tool on a deliberately vulnerable lab app is a fair sanity check, but your own app is the real test.
A short buying sequence
- Write your requirements first. List your login type, front end framework, API style and environments before you see a demo.
- Shortlist by fit, not by feature count. A tool that handles your login and your single-page routes beats one with a longer checklist.
- Run a trial on a copy of staging. Use your own app, a dedicated account and synthetic data.
- Measure coverage. Compare routes visited with routes that exist.
- Triage a sample of findings. Reproduce ten findings by hand and count how many are real.
- Check operations. Look at scan time, resource use, scheduling and how results reach your ticket system.
- Review data handling. Read the vendor's answers on credential storage, retention and deletion.
- Decide and record why. Keep the scorecard so a later review can see the reasoning.
A buyer who follows these steps learns more in two weeks than a month of presentations would show. Keep the trial narrow, use real flows, and treat missing answers as unknowns, not as passes.
How to use these answers
Print the ten questions and use them as a trial checklist. For each, write what you saw, not what the vendor said. Keep the notes with the scan records, so a later decision can be explained.
Where Safeguard fits
DAST covers the running web layer. For the open source inside your applications, Safeguard offers SBOM and dependency scanning with reachability analysis, and a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch a scan from start to results, and match each stage to the questions above.
Quick check
Is DAST enough on its own?
No. It misses business logic flaws and library issues, so pair it with code review, dependency analysis and manual testing.
Can DAST run without a login?
Yes, but it then tests only the public surface. Add a test account to cover protected pages.
Should I judge a tool by a lab app score?
Use it as a sanity check only. Your own staging copy is the better test.
Sources
- OWASP DevSecOps Guideline: Dynamic Application Security Testing
- OWASP Web Security Testing Guide: Business Logic
- ZAP: Baseline Scan
- ZAP: Full Scan
- ZAP: Scan Policy dialog
Last reviewed: 19 October 2026.
