In depth
Dynamic Application Security Testing (DAST) probes a running application — typically over HTTP/HTTPS — from the outside. The scanner crawls or is fed a list of endpoints, sends crafted payloads (SQL injection markers, XSS vectors, command-injection sequences, path-traversal strings, SSRF callbacks), and analyses the responses for evidence that a payload was reflected, executed, or caused a measurable behavioural change. Burp Suite Pro's active scanner, OWASP ZAP, Nuclei, Acunetix and Invicti are the most common production tools; in CI pipelines, Nuclei templates and ZAP's baseline scan are the lightweight options.
DAST's strength is that it finds real issues in the deployed system. It does not care whether the application is written in Go, Python, Java or Rust, whether the framework is Django or Spring, or whether the source code is available — it observes only what the network sees. This makes DAST particularly useful against third-party components, legacy applications without buildable source, and the integration layer between services. Authenticated DAST (where the scanner is given a valid session) finds vastly more than unauthenticated scanning, especially on modern SPA + API architectures.
The weaknesses are the inverse of SAST's strengths: DAST runs late in the cycle, finds issues only in code paths it actually visited, and is poor at second-order bugs (where the payload is stored now and rendered or executed later in a different request). It also has a notoriously high false-positive rate on bespoke applications — a scanner cannot tell that a 500 response is the normal behaviour of an idempotent endpoint that is being hit twice. Every Burp Suite Pro or Nuclei finding in an AxVeil report is manually validated by a human tester before it lands in the deliverable; raw scanner output is not a deliverable.
DAST is mandatory under several frameworks — PCI DSS v4.0 Requirement 11.4.1 (penetration testing) and OWASP ASVS V14 (configuration). See Nuclei templates explained for a worked example of templated DAST in production.
DAST's strength is that it finds real issues in the deployed system. It does not care whether the application is written in Go, Python, Java or Rust, whether the framework is Django or Spring, or whether the source code is available — it observes only what the network sees. This makes DAST particularly useful against third-party components, legacy applications without buildable source, and the integration layer between services. Authenticated DAST (where the scanner is given a valid session) finds vastly more than unauthenticated scanning, especially on modern SPA + API architectures.
The weaknesses are the inverse of SAST's strengths: DAST runs late in the cycle, finds issues only in code paths it actually visited, and is poor at second-order bugs (where the payload is stored now and rendered or executed later in a different request). It also has a notoriously high false-positive rate on bespoke applications — a scanner cannot tell that a 500 response is the normal behaviour of an idempotent endpoint that is being hit twice. Every Burp Suite Pro or Nuclei finding in an AxVeil report is manually validated by a human tester before it lands in the deliverable; raw scanner output is not a deliverable.
DAST is mandatory under several frameworks — PCI DSS v4.0 Requirement 11.4.1 (penetration testing) and OWASP ASVS V14 (configuration). See Nuclei templates explained for a worked example of templated DAST in production.