DAST is black-box by design. It reflects the externally visible attack surface well but does not see internal logic or paths unreachable from the client. That is why it pairs with SAST and pentesting: each technique looks at a different angle.
What DAST is
DAST (Dynamic Application Security Testing) is the security analysis of an application while it is running, observed from the outside without access to the code. The tool starts up as a user would, crawls the application, identifies forms, endpoints and APIs, and fires payloads designed to surface the usual classes of vulnerability: SQL and command injection, reflected and persistent XSS, broken authentication and authorisation, sensitive data exposure, default configuration, weak session management. The test catalogue typically maps to OWASP Top 10 and OWASP ASVS. Unlike SAST, which needs the code, DAST is a black-box exercise and sees what an attacker sees: real configuration, effective authentication and runtime behaviour.
Why it matters
For a security leader with applications exposed to the internet, the thing that actually matters is the real exposure of the service in production, not its theoretical exposure in the code. DAST delivers that view: it surfaces issues that only appear once the application is assembled (misconfigured security headers, cookies without secure attributes, open redirects, tokens that survive logout, error pages that leak stack traces) and it can be re-run every time a change ships. It fits naturally inside CI/CD against staging and acts as a sensible first filter before spending manual pentest capacity. The classic trap is to cover only what the crawler finds on its own and leave the authenticated APIs out — which is where most of the business logic lives, and where most of the impactful vulnerabilities live.
Key points
For DAST to pay off it needs credentials and route information. Without an authenticated session the scanner only walks the public surface and leaves about eighty percent of the application untested. Configuring robust authentication (including simulated MFA where it applies) and providing route maps or an OpenAPI spec multiplies coverage.
APIs need separate treatment. Crawling a REST API does not work; the scanner needs the contract (OpenAPI, GraphQL introspection or a Postman collection) to generate valid requests. Without the spec, DAST covers HTML forms and skips the layer where the business logic actually sits.
False negatives are more expensive than false positives. An injection or authentication flaw the scanner misses still lives in the application when the pentest or the attacker arrives. Calibrating the tool against a small set of intentional staging vulnerabilities and measuring the catch rate is worth the time before trusting the output.
DAST does not replace manual pentesting. Business-logic flaws, abuse of functionality and multi-step chains remain a human task. What DAST does is prevent the pentest from spending its time on classes the scanner should have caught.
A WAF in front can muddy the results. The common pattern is to run DAST against a route that bypasses the WAF (preprod, IP allowlist) so that the test measures the application and not the WAF. If the scan must run in production behind the WAF, report it that way to avoid confusing blocking with remediation.
Example: DAST across a portfolio of web applications and APIs
A company runs four web applications and roughly a dozen internet-facing microservices exposed as APIs and decides to fold DAST into its security programme. The pipeline triggers the scanner against staging every night in three modes: anonymous (public surface), authenticated as a standard user and authenticated as an administrator. For the APIs, the OpenAPI specification versioned in the repository is plugged into the scanner and a contract-driven pass is executed. Findings land in the same management system as those from SAST and the external scanner, deduplicated and enriched with asset criticality.
By the second cycle a pattern emerges: three of the four applications carry reflected XSS in forms the team had marked as sanitised; the scanner finds them because it probes with a broader payload set than the developers had considered. The fourth has an open redirect on the login flow that would make a perfect pivot for a phishing campaign. The follow-up manual audit no longer wastes time on those vectors: it concentrates on business logic and authorisation and uncovers two API authorisation flaws that no automated tool would have found. The programme now produces three complementary outputs (SAST, DAST, pentest) instead of three overlapping reports.
Common mistakes
- Running anonymous DAST and assuming the application has been tested. Without an authenticated session the scanner sees only the home page and the login form. Real coverage needs test users with different permissions and, for APIs, the OpenAPI contract.
- Running DAST against production behind the WAF without saying so. The report ends up measuring the WAF, not the application; findings appear minor when in fact the blocking comes from an external control that could fail.
- Trusting the crawler alone to discover endpoints. APIs and dynamic routes do not surface that way. Without a spec or a manual sitemap, the part of the application with the most business logic ends up untested.
- Ignoring false positives instead of managing them. Developers lose patience quickly if the tool marks everything as critical. Without a documented way to flag false positives with sign-off and expiry, DAST loses credibility.
- Assuming DAST covers OWASP Top 10 in full. It covers injection, XSS, open redirects and headers well; it covers broken authorisation, business logic and multi-step authentication poorly. That part belongs to the pentest.
Related terms
Related services
This concept may be related to services such as:
Frequently asked questions
How does DAST differ from SAST?
DAST probes the application at runtime as a black box: it sees real configuration, effective authentication and runtime behaviour. SAST inspects the code without executing it: it sees internal logic, unreachable paths and secrets pasted into the repository. They are complementary, and a serious application security programme uses both.
Does DAST cover the whole OWASP Top 10?
It covers injection, XSS, open redirects, default configuration and security headers well. It covers broken authorisation, business-logic flaws and multi-step chains poorly. That part needs manual pentesting; DAST clears the easy ground so the pentest focuses where it adds value.
Does DAST need credentials to be useful?
Yes. Without an authenticated session the scanner walks the public area and leaves most of the application untested. Prepare test users with different permission levels (user, admin, read-only) and, for APIs, plug in the OpenAPI contract so the scanner generates valid requests.
Can I run DAST against production?
You can, with two caveats. Warn the operations team so the scanner is not mistaken for an attack, and decide whether to test behind the WAF (measures application plus WAF) or bypassing it (measures only the application). The usual choice is to run against a staging environment identical to production and, if production is in scope, with destructive scans disabled.
How does DAST integrate into CI/CD?
The common pattern is a lightweight scan against the ephemeral environment of each pull request to catch big regressions, and a full nightly scan against staging. Blocking gating is usually reserved for critical categories (injection, broken authentication); for the rest the report serves the team without slowing delivery.