What is DAST?Dynamic Application Security Testing explained
Tests a running web application or API with malicious inputs and analyzes the responses, finding vulnerabilities that appear only when the complete application is deployed.
By Cyber Tool Stack Editorial TeamReviewed
Verified Sources: owasp.org, ibm.com, devguide.owasp.org
The lesson
Attacking your own app before someone else does
The surest way to know whether your website can be hacked is to try hacking it — safely, automatically, and on a schedule. This lesson explains how a scanner probes a running app from the outside, exactly the way an attacker would.
If it helps, think of it as… the hired locksmith
Before moving in, you hire a trusted locksmith to walk around the finished house and try everything a burglar would: jiggle each lock, push on every window, test whether the side gate really latches. They steal nothing — they just hand you a list of which doors opened, how, and what to fix before someone less friendly tries the same.
Crawl
Map every page, form, and API endpoint
Attack
Send malicious inputs to each one
Observe
Read responses for signs a probe worked
Verify
Confirm real findings, discard false alarms
Report & retest
File findings, re-run on the next release
…then the loop starts again — this runs continuously, not once.
What it does
Dynamic application security testing (DAST) tests a web application or API while it's actually running, by sending it deliberately malicious requests and reading how it responds. "Dynamic" is the contrast with static testing: instead of reading the source code, a dynamic scanner interacts with the live application from the outside, with no special access — the same view an attacker on the internet has. Security people call this black-box testing.
Because it tests the assembled, running system, DAST finds problems that never appear in the code itself: a server configured to reveal too much, a login flow that can be skipped, two components that are each fine alone but unsafe together. It doesn't care what language the app is written in — if the app speaks HTTP, it can be tested.
The attack it stops
A team ships a new search feature. The code review looked fine, but in production the feature echoes whatever the user typed back into the page. An attacker crafts a link that plants script in that echo — a cross-site scripting attack, one of the perennial entries in the OWASP Top 10 list of web application risks — and uses it to hijack the sessions of anyone who clicks.
A dynamic scanner run against the staging site finds this the same week the feature is built. It submits a harmless probe string into the search box, sees that string come back unescaped in the response, and verifies the page will execute planted script. The team gets a reproducible finding — the exact request that worked — before any real user was ever exposed.
How it works, step by step
- The scanner crawls the running application, following links and submitting forms to map every page, input, and API endpoint — including logging in first, so pages behind authentication get tested too.
- For each input it discovers, it sends attack payloads: database syntax, script fragments, path tricks, malformed data.
- It watches the responses for tells — error messages, reflected payloads, timing changes — that indicate a probe landed.
- Promising hits are verified with follow-up requests to confirm the flaw is real and exploitable, cutting false alarms.
- Findings are reported with the exact reproduction steps, and the scan re-runs automatically on each new release to catch regressions.
What it doesn't do
A dynamic scanner can only test what it can reach: pages it fails to crawl and features hidden behind complex workflows go untested. It reports symptoms, not the guilty line of code — a developer still has to trace the finding back to its cause. And because it needs a running app, its findings arrive later in development than static analysis, when fixes cost more.
The common beginner misconception is that an automated scan equals a penetration test. A scanner is tireless and consistent, but it won't chain small oddities into a business-logic attack — "what if I change the price in my own cart?" — the way a human tester will.
How it fits the stack
DAST is the outside-in counterpart to SAST, which reads the code from within — mature teams run both and compare notes. Confirmed findings feed the vulnerability management process for prioritization and tracking, and a WAF can shield a confirmed flaw in production while the fix works through the pipeline.
Terms you just met
Each links to its plain-language definition in the glossary.
The field guide
Evaluating this category
A second pass for buyers: market context, distinctions that matter, and what to weigh when tools in this category start looking alike.
An application can pass every code review and still fail the moment it meets the internet, because some vulnerabilities only exist once the pieces are actually running together — a misconfigured server, an authentication check that works in isolation but not across two services, a default credential nobody changed. Dynamic application security testing finds these by treating a running application the way an attacker would: sending it malicious input over the network and watching how it responds, with no visibility into the source code behind it.
That black-box approach tests the same interface an actual attacker faces, catching classes of bugs that reading source code alone would never reveal.
The problem it solves
Code that looks correct can still be insecure once it's deployed, integrated with other services, and configured for a real environment. A test built only around source review misses broken authentication across microservices, a security header dropped by a load balancer, or an endpoint that behaves differently under load than in a unit test.
Someone has to test the application the way an outside attacker actually would — probing the live, deployed system — and do it repeatedly, because every deployment can reintroduce a problem a previous scan already cleared.
How it works
A scanner starts by crawling the target, discovering pages, forms, and API endpoints the way a browser or an API client would. It then sends a library of crafted, malicious payloads to each input and inspects the response for signs something went wrong — a leaked internal error, a payload reflected back unescaped, a response time suggesting a query was manipulated.
Testing behind a login is essential, since most real functionality — and risk — lives there, so scanners need valid credentials or a recorded session to crawl authenticated areas. Modern applications talk more through APIs than rendered pages, so scanning REST and GraphQL endpoints directly has become as important as scanning traditional pages. Because dynamic testing produces false alarms from odd-but-harmless behavior, better tools automatically verify a finding is truly exploitable before it reaches a person, and the whole scan can run automatically as a stage in the deployment pipeline.
DAST vs SAST
Dynamic testing attacks a running system with no view of its source; static testing reads the source with no system to attack. DAST finds environment and integration problems invisible to source review, but only within whatever it manages to crawl, and only after the application exists somewhere to attack. It also can't point at a line of code the way static analysis can — a finding has to be traced back by hand. Programs that rely on just one discipline leave a predictable gap; combining both catches what either alone would miss.
Choosing one
Authentication handling is the first filter: a scanner that can't reliably log in and stay logged in will only ever test the small, low-value part of an application that's public. Ask specifically how it handles multi-step logins and modern single-page apps, since that's where scanners most often fail quietly.
Weigh API scanning as seriously as web scanning if APIs make up a meaningful share of the attack surface — many organizations now have far more API endpoints than web pages, and a scanner tuned only for browsable pages will miss most of them. Finally, decide how much automation the scan needs: an occasional security-team scan has different requirements than one meant to gate every deploy, where speed and clean CI/CD integration matter more than exhaustive depth.
Capability taxonomy
What buyers typically evaluate when comparing tools in this category.
- Black-box scanning
- Tests a running application from the outside, without access to source code.
- Authenticated scanning
- Crawls and tests pages that require a logged-in session.
- API scanning
- Tests REST and GraphQL APIs, not just traditional web pages.
- CI/CD scan automation
- Runs scans automatically as part of the build and deploy pipeline.
- Automated finding verification
- Confirms exploitability of findings to cut down false positives.
- OWASP Top 10 coverage
- Tests for the industry-standard set of common web application vulnerability classes.
Tools in this category
Now that you know what DAST does, see who does it.
8 tools