Security Engineering
Intermediate 16 min read Security Engineering

DAST: Dynamic Testing on a Running App

Test the running application the way an attacker would: crawling, injection probes, and authen-thresholding — on environments you control.

DASTZAPactive scanOWASP ZAPcrawlingconfig vs runtime
Introduction

What is this?

DAST (Dynamic Application Security Testing) attacks a running application with real HTTP requests to uncover vulnerabilities visible from outside — no source code required.

Motivation

Why do you need it?

  • DAST sees what SAST can't: the behavior of assembled dependencies, config, and wiring at runtime.
  • It tests 'can an unauthenticated attacker actually do this' — the question SAST answers poorly.
  • ZAP and peers make baseline scans a five-minute CI chore, catching config-drift regressions.
Think about it

Mental model

Imagine

Reading the car's service manual

Think of

Test-driving the finished car

The manual (SAST) knows the parts; the road test (DAST) discovers what they actually do together.

Mechanics

How it works

  • Spider/crawler maps the app's routes from a starting URL (your own staging).
  • Active scans replay requests with payload injections (SQLi, XSS, path traversal, header checks).
  • Auth-aware scans replay as an authenticated session to cover gated routes.
  • Results arrive as findings with request/response evidence ready for triage.

DAST against a staging app

Spider
Auth
Probe
Report
Triage
Real world

In production

  • A startup runs a ZAP baseline nightly against staging and catches a config regression the unit tests missed.
  • A pentest uses DAST output as the map, then manually verifies the top findings to remove noise.
  • A SOC teams scans its own login flows to size brute-force resistance before legal red-team week.
Guidelines

Best practices

  • Target staging/test environments you own; never point DAST at third-party or production without explicit scope.
  • Run with auth-enabled sessions to cover routes your users actually reach.
  • Set timeouts and harnesses so the scan cannot hammer the target into an outage — rate-limit deliberately.
  • Pair with SAST: DAST finds what shipping assembled, SAST finds what coding introduced.
Watch out

Common mistakes

  • Scanning production 'to check the patch' and triggering the WAF, altercation, and a support ticket.
  • Letting the spider wander into admin or cross-tenant data routes in a shared staging.
  • Running unauthenticated scans only, believing the auth-gated flaws don't exist.
  • Publishing a raw DAST dump as 'the report' without any manual confirmation.
When things break

Debugging tips

  • When a scan reports no findings on gated routes, confirm the auth session actually replays.
  • Inspect the exact request the scanner sent; false positives are often scanner-specific artifacts.
  • Re-run the repro on the same build after a fix; the regression check is the whole point.
Security

Security considerations

  • DAST actively sends attack traffic — keep it scoped, rate-limited, and on dedicated test envs.
  • Session tokens used by the scanner are real credentials; store them in the scan config, not the logs.
Interviews

Interview checkpoint

Practice

Hands-on lab

Nightly-Style DAST Baseline Against a Local Staging App
45 min · intermediate
In progress
Objectives
  • Run ZAP in baseline mode against local staging (DVWA).
  • Review a handful of findings with evidence.
  • Design the 'CI won't false-fail' gate tweaks.

Nightly-Style DAST Baseline Against a Local Staging App

45 min · intermediate

0/4 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/2
1

DAST is most valuable for...

2

An unauthenticated DAST scan alone...

Go deeper

Official documentation