Dynamic Application Security Testing
Dynamic Application Security Testing, or DAST, checks a running application for security weaknesses by interacting with it the way an attacker would, without looking at its source code. A DAST tool sends unexpected or malicious input to a live app and watches how it responds, which catches problems like injection flaws or broken login checks that only show up once the software is actually running.
itOffensive security and application security | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Intro
Dynamic Application Security Testing
Dynamic Application Security Testing (DAST) is a non-functional testing process that identifies security weaknesses and vulnerabilities in an application by interacting with it while it runs. A DAST tool talks to your application through its front end, the same way a browser or an API client would, and looks for behavior that reveals a flaw.
The useful mental model is black-box interaction with a live target:
crawl the app → send probing input → observe the response → triage the finding
↑ ↓
└──────────────── expand coverage, rescan, retest ─────────┘
DAST tools do not read your source code. They do not know your framework, your language, or your internal architecture. They only know what the application exposes at its interfaces — pages, forms, headers, cookies, and API endpoints — and what it does when it receives something unusual.
What DAST tests, and what it does not
DAST is one member of a family of application security testing techniques, and each one inspects a different slice of the application:
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://devguide.owasp.org/en/06-verification/02-tools/01-dast/
Supports
- Core definition of DAST as a non-functional testing process identifying weaknesses in a running application
- DAST as black-box testing that communicates through the front end without source-code access
- DAST tools detect vulnerabilities by performing attacks
- Coverage limitation — DAST cannot cover 100% of an application's source code, so effectiveness is judged by attack-surface coverage
- Manual assessment complements automated tools for business logic, race conditions, and certain zero-day classes
- Claims and quiz answers about DAST's definition, black-box nature, and coverage limits
- https://owasp.org/www-project-security-culture/v11/7-Security_Testing/
Supports
- SAST provides feedback upon commit of source code, before execution
- DAST is testing performed on the running application, typically pre-production
- SCA checks for vulnerabilities in third-party libraries
- The comparison table of SAST/DAST/SCA in 01-intro.md, 02-slides.md, and 03-cheatsheet.md
- Quiz question on DAST's lifecycle timing
- https://owasp.org/www-project-devsecops-guideline/latest/02b-Dynamic-Application-Security-Testing
Supports
- DAST as black-box testing that injects malicious payloads to find vulnerabilities like SQL injection and XSS
- DAST is especially helpful for detecting input/output validation issues, authentication problems, and server configuration mistakes
- DAST tools allow sophisticated client- and server-side scans without needing source code or framework knowledge
- DAST requires minimal interaction once configured and can run as part of a nightly scan
- Three DAST tool categories: dynamic security scanners, fuzzers, and attack proxies
- Named tools including ZAP (open source), Acunetix, Burp Suite, Veracode Dynamic Analysis, and others
- Pipeline placement guidance — a scanning stage added after deployment to a staging environment, triggered via API call to the deployed URL
- Claims and quiz answers about pipeline placement and DAST's detection strengths
- https://owasp.org/www-project-web-security-testing-guide/
Supports
- WSTG described as the premier cybersecurity testing resource for web application developers and security professionals
- WSTG as a comprehensive guide to testing the security of web applications and web services
- The WSTG-<category>-<number> identifier format
- Quiz answer on using WSTG as a structured coverage checklist
- https://owasp.org/www-project-web-security-testing-guide/stable/
Supports
- The twelve named WSTG testing categories (information gathering through API testing) used in 01-intro.md, 02-slides.md, and 03-cheatsheet.md
- The WSTG category-code table in 03-cheatsheet.md
- https://www.zaproxy.org/
Supports
- ZAP described as the world's most widely used web app scanner, free and open source
- ZAP positioned as a DAST tool for beginners and security professionals, with automation and an add-on marketplace
- The 06-links.yaml rationale for the ZAP homepage entry
- https://www.zaproxy.org/getting-started/
Supports
- ZAP's workflow — exploration via spidering or manual browsing, passive scanning during exploration, active scanning after mapping, and alert review
- Passive scanning does not change responses and is considered safe
- Active scanning attempts to find vulnerabilities using known attacks
- Explicit guidance to only use ZAP to attack an application you have permission to test with an active attack
- ZAP's automation options — Automation Framework, Docker, GitHub Actions, API/daemon modes
- Quiz answers on active-scan authorization and finding verification/triage
- https://www.zaproxy.org/docs/desktop/start/features/authentication/
Supports
- Each Context has an Authentication Method defining how authentication is handled
- Authentication Method and Verification Strategy define the process; credentials depend on the user
- Requirement to configure a Logged In Indicator or Logged Out indicator for the Authentication Verification Strategy
- Session Management Method configuration for a context
- The authentication checklist in 03-cheatsheet.md and the authenticated-scan quiz question
- https://portswigger.net/web-security
Supports
- Web Security Academy described as free, online web security training from the creators of Burp Suite
- Free interactive labs with progress tracking, covering injection, XSS, CSRF, authentication, and API security
- The 06-links.yaml rationale for the Web Security Academy entry as an advanced, hands-on next step
- https://portswigger.net/burp/
Supports
- Burp Suite positioned as "the world's
- Burp Suite's dual role as an automated dynamic vulnerability scanner and a manual testing toolkit
- The 09-awesome-links.yaml rationale for the Burp Suite entry
- https://github.com/enaqx/awesome-pentest
Supports
- Curated selection of DAST-relevant tools for 09-awesome-links.yaml — Burp Suite, Nikto, sqlmap, mitmproxy, ZAP, Wapiti, FuzzDB, and their one-line descriptions
- Categorization of tools into web vulnerability scanners, intercepting proxies, and injection/fuzzing tools
- mitmproxy described as an interactive, TLS-capable intercepting HTTP proxy for penetration testers, supporting the 09-awesome-links.yaml mitmproxy entry
- https://cirt.net/nikto/
Supports
- Nikto as a black-box web server scanner
- The 09-awesome-links.yaml rationale for the Nikto entry
- https://projectdiscovery.io/nuclei
Supports
- Nuclei as a fast, template-based (YAML DSL) vulnerability scanner with community-contributed templates
- The 09-awesome-links.yaml rationale for the Nuclei entry
- https://sqlmap.org/
Supports
- sqlmap as an automatic SQL injection and database takeover tool
- The 09-awesome-links.yaml rationale for the sqlmap entry
- https://wpscan.com/
Supports
- WPScan as a WordPress security scanner backed by a maintained vulnerability database
- The 09-awesome-links.yaml rationale for the WPScan entry
- https://wapiti-scanner.github.io/
Supports
- Wapiti as a free, open-source, Python black-box web application vulnerability scanner with a built-in fuzzer
- The 09-awesome-links.yaml rationale for the Wapiti entry
- https://github.com/fuzzdb-project/fuzzdb
Supports
- FuzzDB as a dictionary of attack patterns and primitives for black-box application fault injection
- The 09-awesome-links.yaml rationale for the FuzzDB entry
