Skip to content
sec/atlas
back to the map
testing technique
stage: staging
2 min read

DAST

Attacks the running application the way a malicious user would, without seeing the code.

OWASP ZAPBurp SuiteNuclei

What it is

(Dynamic Application Security Testing) tests the running application from the outside in, as a black box: the scanner sends malicious requests and observes the responses, as an attacker would, without access to the source code.

Because it operates on the real, assembled system, DAST validates what does not see: server configuration, HTTP headers, authentication, session and the interaction between components.

How it works

  • crawling: a spider maps the application's endpoints, forms and parameters
  • fuzzing: every discovered input receives attack payloads (, , path traversal, SSRF)
  • response analysis: the scanner checks whether the attack was reflected, executed or leaked information
  • passive checks: missing headers, cookies without flags, exposed versions

An attack in practice

The scanner found an id parameter in the crawler. First step: the classic SQL injection test, closing the quote and inserting an always-true condition. What the scanner sends:

test requesthttp
GET /users?id=1'%20OR%20'1'='1 HTTP/1.1
Host: shop.example.com

What gives the flaw away

The SQLi signature is in the response: instead of one user, all of them came back, because the injected condition became part of the query. The scanner compares this response with the baseline of the original parameter and concludes: injectable.

response (200 OK)http
200 OK
[ {"id": 1, "name": "Ana"}, {"id": 2, "name": "Beto"},
  {"id": 3, "name": "Caio"}, ... ]   <- all the users

When there is no echo: blind injection

The response does not always return the data, and modern engines hide the error. For these cases, the scanner uses blind injections and infers from behavior. A controlled delay is the evidence:

time-based blind injectionhttp
GET /users?id=1'%20AND%20SLEEP(5)--  HTTP/1.1

with the payload:     response in 5.2 s
without the payload:  response in 0.1 s
                  => the database ran the SLEEP: blind injectable

Where it fits in the pipeline

After deploying to staging or preview: the pipeline brings up the environment and points the scanner at it, failing on critical findings. Scheduled scans against production cover what changes outside the release cycle.

Strengths and limitations

  • strength: reports what is actually exploitable, with a very low false positive rate, because it only asserts what it triggered
  • strength: language-agnostic, since it tests HTTP, not code
  • weakness: only sees the exposed surface; code without a reachable route is left out
  • weakness: slow and late, finding issues after deploy, when fixing is already costly
DASTDynamic testing: attacks the running application from the outside, as a black box.see in glossary →SASTStatic analysis: examines the code without running it. It finds issues through flow analysis, not guesswork.see in glossary →SQL injectionSQLiInput concatenated into a SQL string is parsed as part of the query. Parameterized queries send the values separately and remove the problem.see in glossary →XSScross-site scriptingInjection into a web page: untrusted input is rendered as HTML or script in another user's browser. Escape on output by context and add a Content-Security-Policy.see in glossary →

connections on the map

updated on 14/10/2026 · sources to go deeper · report an error

in other domains

Study before

Unlocks

test what you learned

Loading questions…