# DAST Scanning

DAST (Dynamic Application Security Testing) performs black-box security testing against live web applications and APIs. Unlike SAST which analyzes source code, DAST tests running applications by sending crafted requests and analyzing responses for vulnerabilities.

## DAST Overview

Navigate to **DAST** in the sidebar to see the overview page.

![DAST overview with scan runs and finding counts](/screenshots/dast-overview.png)

The overview shows:

- Total DAST scans performed
- Total DAST findings discovered
- Number of active targets
- Recent scan run history with status, phase, and finding counts

## Managing Targets

Navigate to **DAST > Targets** to configure applications to test.

### Adding a Target

1. Enter a **target name** (descriptive label)
2. Enter the **base URL** (e.g. `https://staging.example.com`)
3. Click **Add Target**

### Target Settings

Each target supports these settings:

| Setting | Description |
|---------|-------------|
| **Target Type** | WebApp, REST API, or GraphQL |
| **Max Crawl Depth** | How many link levels to follow |
| **Rate Limit** | Maximum requests per second |
| **Destructive Tests** | Allow DELETE/PUT requests |
| **Excluded Paths** | URL paths to skip during testing |

### Authentication

DAST supports authenticated scanning so it can test pages behind login:

| Method | Description |
|--------|------------|
| **None** | No authentication |
| **Basic** | HTTP Basic Auth with username and password |
| **Bearer** | Bearer token in the Authorization header |
| **Cookie** | Session cookie value |
| **Form** | Login form with URL, field names, and credentials |

::: warning
Authenticated scans access more of the application surface. Only test applications you own or have explicit authorization to test.
:::

## Running a DAST Scan

Click the **Scan** button on any target row. The scan progresses through:

1. **Crawl** -- discovers pages, forms, and API endpoints by following links and analyzing JavaScript
2. **Test** -- sends attack payloads to discovered parameters
3. **Report** -- collects results and generates findings

## Viewing DAST Findings

Navigate to **DAST > Findings** to see all discovered vulnerabilities. Each finding shows:

| Column | Description |
|--------|-------------|
| Severity | Critical, High, Medium, Low, or Info |
| Type | Vulnerability category (SQL Injection, XSS, SSRF, etc.) |
| Title | Description of the vulnerability |
| Endpoint | The HTTP path that is vulnerable |
| Method | HTTP method (GET, POST, PUT, DELETE) |
| Exploitable | Whether the vulnerability was confirmed exploitable |

Click a finding to see full details including the CWE identifier, vulnerable parameter, remediation guidance, and evidence showing the exact request/response pairs that triggered the finding.

### Filtering Findings

The findings page provides several filters to help you focus on what matters:

| Filter | Description |
|--------|-------------|
| **Search** | Free-text search across finding titles and descriptions |
| **Severity** | Filter by severity level (Critical, High, Medium, Low, Info) |
| **Vulnerability Type** | Filter by vulnerability category -- supports all 21 DAST vulnerability types including SQL Injection, XSS, SSRF, CORS Misconfiguration, CSP Bypass, and more |
| **Exploitable** | Show only confirmed-exploitable findings, or only unconfirmed |

Filters can be combined. A count indicator shows how many findings match the current filters out of the total (e.g. "Showing 12 of 76 findings"). When no findings match the active filters, a message distinguishes between "no findings exist" and "no findings match your current filters."

::: tip
Findings marked as **Confirmed** exploitable were verified with a successful attack payload. **Unconfirmed** findings show suspicious behavior that may indicate a vulnerability but could not be fully exploited.
:::

## Deterministic detectors (planned)

The DAST engine above is agentic: an LLM drives crawler, browser and testing tools and decides what to try next. That gives depth and code-aware exploitation, but not run-to-run reproducibility. The next step (decided 2026-08-31, not yet implemented) adds two deterministic open-source detectors **under** the agents: **Nuclei** (template checks incl. ICS/OT and default-credential templates) first, then an **OWASP ZAP** baseline scan. Their findings will appear alongside agent findings, carry CWE + compliance `control_refs`, and seed the agent's context so it verifies and chains instead of rediscovering. See [Tools & Scanners](/reference/tools#planned-integrations-decided-2026-08-31-not-yet-in-the-code).