DAST tests a running application from the outside, sending real requests the way an attacker would, to find weaknesses that only appear once the code is deployed.
The short answer
DAST stands for dynamic application security testing. A DAST scanner crawls your live application, submits crafted inputs to every form, parameter and endpoint it finds, and reports where the application responds in a way that reveals a vulnerability. It sees no source code, which is why DAST finds different problems from SAST.
The distinction that matters: SAST reads what the code says, DAST observes what the deployed application actually does. A flaw introduced by a misconfigured server or a missing header exists only at runtime, so only DAST catches it.
On this page
How DAST works
Because the scanner only knows what it can reach, coverage depends on the crawl. Pages behind a login, or forms reachable only after a multi-step flow, are invisible unless the scanner is given credentials and a path in.
What DAST finds, and what it misses
| DAST finds | DAST misses |
|---|---|
| Injection flaws confirmed by the application’s actual response | Anything in code paths the crawler never reached |
| Cross-site scripting that renders in a real browser context | Business logic abuse, which needs a human tester |
| Missing security headers and weak TLS configuration | Hardcoded secrets sitting in the repository |
| Server misconfiguration and exposed admin interfaces | The exact line of code responsible for a finding |
| Authentication and session handling weaknesses | Vulnerable dependencies, which is SCA’s job |
Why DAST findings are easier to act on
Every result comes with the request that triggered it and the response that proved it. There is far less argument about whether a finding is real, which is the usual reason static findings sit unfixed.
DAST compared with SAST and pentesting
| Approach | Sees | Best at |
|---|---|---|
| SAST | Source code, before deployment | Finding insecure patterns early, pointing at the exact line |
| DAST | The running application, from outside | Confirming what is actually exploitable once deployed |
| Penetration testing | Everything, with a human brain | Chaining flaws and abusing business logic |
They are layers rather than alternatives. SAST runs on every commit, DAST runs against a deployed environment, and a penetration test happens periodically to find what neither tool can reason about.
Running DAST without breaking things
Test staging, not production
An active scan submits real requests. Run it where creating records and triggering emails costs nothing.
Give it credentials
Most of an application sits behind a login. Unauthenticated scans cover the small public part only.
Scan on a release cadence
Full scans take time. Run them per release rather than per commit, and keep SAST on the commit path.
How Osto runs dynamic testing
Osto’s web scanner and mobile app scanner test running applications, and the AI scanner in VAPT categorises findings by severity, pinpoints the affected endpoints and produces remediation and retest reports. Because dynamic testing sits in the same platform as the WAF, a confirmed finding can be read against whether that path is already protected at the edge, which changes how urgently it needs a code fix. Expert-led penetration testing covers the logic flaws no scanner reasons about.
Free security assessment
Test the application an attacker actually reaches
Osto runs web and mobile scanning alongside expert-led VAPT, with findings read against what the WAF already blocks.
Get a free security assessment Book a platform walkthroughScanner plus human testing · Retest included · One platform, everything
Frequently asked questions
What does DAST stand for?
Dynamic application security testing. A DAST tool tests a running application from the outside by sending crafted requests and observing the responses, without access to the source code.
What is the difference between DAST and SAST?
SAST analyses source code before deployment and can point at the exact line. DAST tests the deployed application and confirms what is actually reachable and exploitable. They find different classes of problem, so most teams run both.
Can DAST replace a penetration test?
No. DAST is automated and finds known vulnerability classes reliably. A penetration test adds a human who chains findings together and abuses business logic, which no scanner reasons about. Auditors and enterprise buyers ask for the test, not the scan.
Should DAST run against production?
Prefer a staging environment that mirrors production. Active scanning submits real requests, which can create records, send notifications or trigger workflows. If production is the only option, use a passive or read-only scan profile.
Do compliance frameworks require DAST?
None name the tool. ISO 27001:2022 covers security testing in development under Annex A 8.29, and SOC 2 auditors expect evidence that applications are tested before release. DAST output is one accepted form of that evidence.