What is DAST (Dynamic Application Security Testing)?

Definition

Dynamic Application Security Testing (DAST) is a security testing approach that interacts with a running application to find vulnerabilities. Unlike SAST, which reads source code without executing it, DAST sends inputs to a live application and analyzes its responses — detecting vulnerabilities that only manifest at runtime.

DAST is sometimes called "black-box testing" because it does not require access to source code. The tester interacts with the application through its interfaces — HTTP endpoints, APIs, web forms — just as an attacker would.

How DAST Works

A DAST scanner performs several types of active testing against the running application:

Crawling

The scanner maps the application's attack surface: every endpoint, form, parameter, and entry point it can discover. This map becomes the basis for subsequent testing.

Fuzzing and injection

The scanner sends malicious or malformed inputs — SQL injection payloads, XSS strings, path traversal sequences, oversized inputs — to every discovered entry point and observes whether the application responds in ways that indicate a vulnerability.

Authentication and session testing

The scanner tests authentication mechanisms for weaknesses: brute force susceptibility, weak session tokens, insecure cookie flags, missing HTTPS enforcement.

Response analysis

The scanner analyzes responses for indicators of vulnerability: database error messages that confirm SQL injection, reflected input in HTML that confirms XSS, unexpected file contents that confirm path traversal.

What DAST Detects

DAST is particularly effective at detecting:

• SQL injection and other injection vulnerabilities
• Cross-site scripting (XSS) in rendered responses
• Authentication weaknesses and session management flaws
• Server-side request forgery (SSRF)
• Security misconfigurations exposed at runtime
• Insecure direct object references

DAST in the Security Pipeline

DAST runs against a deployed application — typically in a staging or pre-production environment:

• DAST in CI/CD — automated scanning of staging deployments before production releases
• DAST as scheduled testing — periodic scans of production or staging to catch regressions
• DAST in penetration testing — as a tool used by security teams to supplement manual testing

DAST Limitations

DAST has complementary limitations to SAST:

• Requires a running application — cannot run until late in the development cycle
• Coverage is bounded by what the crawler can discover — endpoints not mapped will not be tested
• No source-level fix guidance — findings describe the behavior, not the code that produced it
• Can produce false positives where injections succeed but are not actually exploitable

DAST and Autonomous Code Governance

DAST confirms what SAST suspects. When a DAST scan validates a vulnerability at runtime, that finding carries higher confidence than a SAST detection alone. Autonomous code governance systems can use DAST-validated findings as high-priority remediation targets — the exploitability is confirmed, making autonomous remediation both urgent and justified.

Hydra integrates DAST findings as one input stream into its prioritization layer, treating confirmed runtime vulnerabilities as highest-confidence candidates for autonomous fix generation.