On this page
What Is DAST (and How Is It Different From SAST)?
DAST tests a running application from the outside by attacking it. Learn how it differs from SAST, what each catches, and what to run for a small app.
Quick answer
- DAST (Dynamic Application Security Testing) scans a running application from the outside, attacking it the way an attacker would.
- SAST reads your source code without running it. Different methods, different strengths, different blind spots.
- DAST’s results reflect real exploitability, but it needs a running environment, seed data, and knowledge of your endpoints.
- For a small app, SAST in CI plus a manual review of auth and access control beats adding a DAST stage.
What is DAST?
DAST (Dynamic Application Security Testing) is a method of finding security vulnerabilities by testing an application while it is running, from the outside, the way an attacker would. The tool sends crafted requests at your live HTTP endpoints and observes the responses for evidence that something is wrong — a database error leaking schema, a request from one user returning another user’s data, a reflected script executing.
The defining property is that DAST has no access to your source code. It is black-box: it knows the URL, sends traffic, and judges what comes back. That is a strength, because a finding it reports is a vulnerability that genuinely reproduced against a running system, not a pattern match in a file that may or may not be reachable.
Where this bites vibecoders
The specific way this bites vibecoders is the false sense of coverage. A DAST scan that reports “no vulnerabilities” on an app with no authentication is not a clean bill of health — it means the scanner never tried to log in, so it tested almost nothing. Without seed credentials and a realistic crawl target, the report is confidently empty and completely uninformative, which is worse than not running it.
How do DAST and SAST differ?
| Dimension | SAST | DAST |
|---|---|---|
| Analyzes | Source code | A running application |
| Access to code | Full | None |
| Runs the app | No | Yes |
| When it runs | On every commit, in CI | Against a running environment |
| Needs test data | No | Yes — an account, seeded records |
| Understands your routes | Yes, it parses them | No, it must discover or be told |
| Finds | Injection sinks, weak crypto, missed auth checks | Real, reproducible exploits on live endpoints |
| False positives | Higher — pattern-based | Lower — the finding reproduced |
| Catches auth/access bugs | Poorly — this is the “does it call the auth check” problem | Well — it can actually try other users’ IDs |
| Cost | Cheap, fast | Expensive, needs environment and time |
The practical consequence: SAST finds bugs you can see in the code; DAST finds bugs you can see in the behaviour. They are not substitutes.
What does each catch that the other misses?
SAST sees patterns that are dangerous regardless of reachability — string concatenation into a query, a hardcoded credential, a call to a weak hash, a route with no authentication decorator. It is fast enough to run on every commit, which is why it is the foundation of most pipelines.
SAST’s blind spots are exactly the bugs where the code looks right: a route that authenticates the user but then queries by an ID taken from the request body instead of the session. Nothing in the source is wrong-looking. This is the single most common serious defect in AI-generated apps, and it is described in What Is Broken Access Control (IDOR)?.
DAST is good at precisely that class, because it can log in as user A, request user B’s resource, and see a 200 with someone else’s data. It is also good at confirming that a SAST finding is actually reachable, and at finding configuration problems — missing headers, permissive CORS, debug endpoints — that only exist in the running system.
DAST’s blind spots are equally real: it cannot see unreferenced code, it cannot reason about code paths no request reaches, and it will not tell you where the bug is, only that a URL responds in a vulnerable way.
When should you run DAST?
Run DAST when you have a running, representative environment and a stable endpoint surface. In practice that means a staging deployment, not production, and it means the app actually works end to end.
It is worth it when:
- You have real authentication, so the scanner can log in as a normal user and test access control between accounts.
- Your API surface is stable enough to crawl and worth re-checking on every release.
- You want to prove a SAST finding is exploitable, or to satisfy a compliance requirement.
- You have a repeatable seeded environment, so results are comparable between runs.
It is not worth it when the app is still changing shape weekly, when there is no staging environment, or when the only way to make it work is pointing the scanner at production.
How do SAST, DAST, and dependency scanning differ?
A third category often gets confused with these two: SCA, or Software Composition Analysis, which scans your dependency tree for known vulnerabilities. It examines neither your code nor your running app — it reads the list of things you depend on.
- SAST — your code, before it runs.
- DAST — your running app, attacked from outside.
- SCA — the libraries you depend on, matched against a vulnerability database.
All three are complementary, and a mature pipeline runs all three. The Software Bill of Materials that SCA produces is a required input for this and for supply-chain review — see What Is a Software Supply Chain Attack?.
Where AI coding assistants get this wrong
- Adding security scanning with no seed account, producing a scan that authenticates as nothing and reports nothing found.
- Treating a clean DAST report as a security sign-off, when the scan never exercised the authenticated paths where the real bugs are.
- Running DAST against production, which is either unsafe or ineffective and can pollute real data.
- Assuming SAST findings are false positives because the first report is noisy — the IDOR and missing-auth findings are the ones that matter, and they look benign.
- Not having an auth pattern at all, so the scanner cannot test whether one user can read another’s data.
- No seeded test data, so every scan explores empty states and paths that error early.
- Adding all three scanners at once to a pipeline with no time budget, then disabling them within a week because they were too noisy to act on.
Checklist
- Put SAST in CI first; it is cheap, fast, and catches the most per minute spent — see How to Add SAST Scanning to a GitHub Repo.
- Add dependency scanning to the same pipeline; it is the cheapest signal of the three.
- Delay DAST until you have a staging environment that mirrors production.
- Seed DAST with real credentials for at least two accounts, so it can test cross-user access.
- Define the crawl scope explicitly rather than letting the scanner wander.
- Point DAST at a representative environment, never production.
- Store scan results per build so regressions are visible rather than averaged away.
- Triage by exploitability, not by count; a scanner that finds 200 issues you ignore is worse than one that finds five you fix.
- Manually review authentication and authorization on every new route regardless of scanner output.
- Re-run on release, not just on commit, so runtime configuration is covered.
FAQ
What is DAST in simple terms?
DAST (Dynamic Application Security Testing) is a security scanner that tests your application while it is running, from the outside, the way an attacker would. It sends requests at your live endpoints and looks for evidence of a real vulnerability, rather than reading your source code.
What is the difference between DAST and SAST?
SAST reads your source code without running it, which is fast and finds problems early but produces false positives and cannot see runtime behaviour. DAST runs your application and attacks it, so its results reflect real exploitability but it needs a running environment, test data, and knowledge of the URLs to probe.
Do I need both SAST and DAST?
For a small application, SAST alone in CI plus a manual review of the access-control and authentication logic is usually a better use of time than adding a DAST stage. DAST earns its cost once there is a running staging environment and a real endpoint surface worth probing automatically.
Is DAST the same as penetration testing?
No. DAST is automated and broad — it probes many endpoints with known attack patterns, cheaply and repeatedly. Penetration testing is human, creative, and targeted at finding the specific flaws automated tools miss. DAST complements a pentest rather than replacing one.
Why did my DAST scan find nothing?
Almost always because it had nothing to test. Without a seeded account, it only probes unauthenticated routes; without seeded data, it walks paths that error immediately; without a defined scope, it may never reach your API at all. An empty report usually means the scan was misconfigured, not that the app is secure.
Can DAST find broken access control?
Better than SAST can, because it can authenticate as one user and request another user’s resource to see what comes back. It is one of the main reasons to run DAST at all, since access-control bugs are the most common serious defect in AI-generated code and are nearly invisible to static analysis.
Related topics
- What Is Static Application Security Testing (SAST)?
- How to Add SAST Scanning to a GitHub Repo
- How to Add Security Scanning to Your CI/CD Pipeline
- What Is Penetration Testing (and Do You Need One)?
- What Is DevSecOps?