Dynamic application security testing (DAST)

How does DAST work?

A DAST scanner treats the application as a black box. It sees only what a browser or API client sees: URLs, forms, parameters, headers, cookies and responses. The work happens in three phases.

1. Discovery. The scanner crawls links and forms, often with a headless browser for single-page apps, and imports any API definition it is given (OpenAPI, GraphQL schema, a Postman collection). The result is a list of endpoints and inputs.
2. Passive checks. Every response is inspected without sending anything extra: missing security headers, cookies without Secure or HttpOnly, stack traces, version banners, mixed content.
3. Active checks. For each input, the scanner sends variations designed to trigger a recognizable reaction: a quote character that breaks a SQL statement, a unique marker string that should come back encoded, a path with ../ sequences, a time delay. It compares the response to a baseline and raises a finding when the difference matches a known signature.

ZAP's documentation puts the nature of that third phase plainly: active scanning "is an attack on those targets," and should only be run against applications you own or are authorized to test.

What does a DAST probe look like?

A probe is an ordinary request with one input changed. Here the scanner appends a single quote to a sort parameter:

GET /api/reports?sort=created_at' HTTP/1.1
Host: app.example
Cookie: session=scan_session_placeholder
Accept: application/json

HTTP/1.1 500 Internal Server Error
Content-Type: application/json

{"error": "syntax error at or near \"'\"", "query": "SELECT id, name FROM reports ORDER BY created_at'"}

The baseline request with sort=created_at returned 200 OK. The quoted version returned a database syntax error that echoes the query, which is strong evidence of SQL injection. A good scanner then sends a follow-up, such as a boolean pair (created_at versus an expression that evaluates the same) or a time-delay test, to confirm the input really reaches the query before it reports the issue. The finding lists the URL, the parameter, the request, and the response that proves it, but not the line of code; for that you need static analysis or a developer.

How do you run an authenticated DAST scan?

Most of an application sits behind a login, so an unauthenticated scan tests the login page and little else. ZAP's authentication documentation states the consequence directly: without configuring authentication, the scanner cannot access any of the protected functionality. A setup procedure that works across tools:

1. Create dedicated test accounts in a staging environment, one per role you want covered (for example user_a as a regular member, admin_test as an administrator). Never scan with a real user's account.
2. Tell the scanner how to log in. Scanners support form-based login, JSON login to an API endpoint, HTTP header authentication, scripted login for multi-step or SSO flows, and a manual option where you log in through the scanner's proxy. For APIs, a bearer token supplied as a header is often simplest.
3. Tell it how to stay logged in. Configure session handling: which cookie or header carries the session, and how to refresh a short-lived token.
4. Tell it how to notice it has been logged out. Set a logged-in indicator (a logout link, the account name in a response) or a logged-out indicator (a redirect to /login). Without this, a scan that loses its session keeps going and reports nothing useful.
5. Exclude destructive actions. Add logout, account deletion, password change, payment and "send email" endpoints to the exclusion list, or the scan will log itself out, delete its own account or spam real inboxes.
6. Seed the crawl. Feed in the API definition and a recorded browser session of the main flows, so the scanner reaches pages that are not linked from the home page.
7. Check coverage afterward. Compare the scanned URL list against the routes you know exist. Endpoints the crawler never reached were never tested.

Scanning as two users of different roles does not by itself test authorization. The scanner does not know that user_a should not see admin_test's pages; it only compares responses to its own attack signatures. Some tools offer an access-control check that replays one user's requests as another, but the rules about who may see what still have to come from a person.

What does DAST miss?

DAST misses flaws whose symptom is a normal-looking response. ZAP's own documentation says that logical vulnerabilities, such as broken access control, "will not be found by any active or automated vulnerability scanning," and the OWASP Web Security Testing Guide makes the same point about business logic: automated tools find it hard to understand context. In practice that covers:

• Authorization flaws. GET /api/projects/project_2210 returning another tenant's data is a 200 OK with valid JSON, identical in shape to a legitimate response. This is broken object level authorization, and the IDOR video walks through this class of bug.
• Business logic. Applying a coupon twice, skipping a checkout step, approving your own request. See business logic vulnerability.
• Multi-step and stateful bugs. Race conditions, flaws that need a specific sequence of requests, second-order injection that fires on a different page.
• Unreached code. Anything the crawler never found, including admin panels, feature-flagged routes and endpoints only a mobile app calls.
• Out-of-band behavior. Blind server-side request forgery or injection with no visible response, unless the tool supports an external callback service.

DAST vs penetration testing

A DAST scan checks known signatures on every input it finds; a penetration test has a person, or an agent directed like one, decide what to try based on what the application does. Both run against a live system, so they are easy to confuse.

The two are complements: DAST catches regressions cheaply between tests, and a pentest covers what scanners structurally cannot. Vulnerability scanning vs penetration testing covers the distinction for infrastructure as well as applications, and authenticated penetration testing covers the role-by-role testing that DAST leaves undone.

Written by Parameter · Last reviewed September 27, 2026