Glossary

What is DAST: probing a running app from outside to find weaknesses

DAST tests a running web app from the outside to find vulnerabilities. How it differs from SAST, IAST and SCA, and how to use it on your own app.

Published 2026-11-15 Updated 2026-11-15 6 min read

On this page

DAST (dynamic application security testing) tests a running application from the outside to find weaknesses. This page explains how it differs from other methods and how to use it on your own app (it does not cover testing other people's sites).

What DAST is

DAST stands for dynamic application security testing. OWASP's DevSecOps Guideline describes it as black-box testing that finds security vulnerabilities and weaknesses in a running application. Black-box means testing only through what is visible from outside, without looking at the internal source code.

In practice, a tool follows the app's pages and input fields, sends test requests, and looks for signs of problems in the responses. The guideline says it is especially useful for input/output validation, authentication issues, and server configuration mistakes.

How it works

1. Point the tool at your own test environment's URL

2. The tool follows pages and input fields and sends test traffic

↓ it watches response content, headers and error behavior

3. It lists signs of problems; a person confirms and fixes them

DAST sends test requests to a running app from outside and looks for problems in how it responds. It does not read the source code.

How it differs from SAST, IAST and SCA

Method	What it examines	Runs the app?	Good for
DAST	The running app's behavior from outside	Yes	Input/output validation, authentication, server configuration
SAST	Source code or compiled code	No	Finding coding problems early in development
IAST	The app's internal behavior (via sensors)	Yes (during tests)	Problems that appear during automated tests
SCA	Libraries and other dependencies	No	Components with known vulnerabilities (CVEs)

For SAST, OWASP lists limits such as finding only a relatively small percentage of application security flaws, many false positives, and missed configuration issues. DAST helps cover that gap but is not complete either. For SCA, see auditing dependencies with OSV-Scanner.

How to use it on your own app (OWASP ZAP example)

ZAP (Zed Attack Proxy; formerly called OWASP ZAP) is a free, open source DAST tool. Its official site now labels it "ZAP by Checkmarx".

Prepare the URL of a test environment you manage. Use a test environment, not production
Run a baseline scan. According to the ZAP documentation it is passive only: it runs the spider (the page-following feature) for 1 minute by default and performs no attacks. It takes a few minutes at most
Read the results and have a person confirm which findings are real; false positives happen
If needed, move to an active scan, in a test environment only. It runs known attacks against the target, and the documentation says it must not be used on web apps you do not own
Re-run it regularly, for example in CI, after each fix

Only against test environments of apps you own or manage

DAST tools send traffic that resembles real attacks. Running them on a site you have no permission to test may count as unauthorized access or disruption of service. The ZAP documentation likewise says not to use the active scan on web apps you do not own. Running it on production can also have side effects, such as creating data or adding load.

What DAST misses

The ZAP documentation says its active scan cannot find logical problems such as broken access control, so manual testing should accompany it. A flaw like IDOR, where one user can see another's data, is hard for an automated tool because it does not know what the correct behavior is. You need to write your own test that requests another user's ID and confirms it is refused.

Configuration checks, on the other hand, are something DAST is good at. For what is worth setting, see security headers: what still matters.

This site's view: DAST is the last net. Think in three layers: code, components, behavior

It is more realistic to combine three methods that look in different places than to expect one tool to find everything: read the code (SAST), check components for known vulnerabilities (SCA), then run the app and test it from outside (DAST). What tools are bad at, "who may do what," you protect with tests you write yourself. Do not trust tool output as is; have a person confirm it before fixing.

Sources (primary)

OWASP DevSecOps Guideline, "Dynamic Application Security Testing" — owasp.github.io (definition of DAST, black-box)
OWASP DevSecOps Guideline, "Interactive Application Security Testing" — owasp.github.io (IAST)
OWASP Community, "Source Code Analysis Tools" — owasp.org (SAST and its limits)
ZAP Documentation, "Active Scan" — zaproxy.org (not for apps you do not own; cannot find logical problems)
ZAP Documentation, "Baseline Scan" — zaproxy.org (passive only; run time)
The description of SCA is a general definition; no single official definition was checked for it

FAQ

QWhat is DAST?

DAST stands for dynamic application security testing. It sends test requests to a running application from the outside to find vulnerabilities and weaknesses. OWASP's DevSecOps Guideline describes it as black-box testing that finds security vulnerabilities and weaknesses in a running application, with no need for access to the source code.

QWhat is the difference between DAST and SAST?

SAST (static application security testing) analyzes source code or compiled code without running it. DAST runs the application and tests it through external requests. OWASP notes that SAST can run early in development, but finds only a relatively small share of flaws, produces many false positives, and often misses configuration issues. DAST suits problems that only show up when the app is running.

QWhat are IAST and SCA?

IAST (interactive application security testing) places sensor modules inside the application and watches its behavior while it is being tested. SCA (software composition analysis) checks the libraries and other dependencies you use for known vulnerabilities. They look in different places from DAST, so they are used together.

QWhat does DAST find?

OWASP's guideline says it is especially useful for input/output validation, authentication issues, and server configuration mistakes. On the other hand, the OWASP ZAP documentation says its active scan cannot find logical problems such as broken access control, so manual testing should accompany it.

QMay I run DAST against someone else's site?

No. The OWASP ZAP documentation states that the active scan must not be used on web applications you do not own. Limit it to apps you own or manage, or where you have clear permission, such as in writing. Using a test environment rather than production is safer.

QWhere should I start with DAST?

Start with an OWASP ZAP baseline scan against the URL of your own test environment. It is passive only: it observes traffic and does not perform attacks. After reviewing the result, move on to an active scan only if needed, and only in a test environment.