DAST (Dynamic Application Security Testing)

DAST tests applications like an external attacker—without source code, solely by interacting with the running application. What SAST looks for in the code, DAST finds in live operation: misconfigured headers, insecure session management, injection vulnerabilities, and logic errors that only arise when components interact.

DAST vs. SAST – Complement, Not a Replacement

SAST (Static Application Security Testing)

Analyzes: Source code, bytecode, binaries
Timing: Early in the development process (Shift Left)
Access: Code repository required
Finds: Insecure code patterns, known bug classes
Weakness: False positives, runtime behavior unknown

// Example SAST finding: SQL concatenation in the code
String query = &quot;SELECT * FROM users WHERE id = &quot; + userId;
// SAST: Warning &quot;Potential SQL Injection&quot;

DAST (Dynamic Application Security Testing)

Analyzes: Running application (HTTP traffic)
Timing: Staging/Pre-Prod, continuous
Access: Only HTTP endpoint required (no code!)
Finds: Real vulnerabilities in running configuration
Weakness: False negatives (not all code paths are reachable)

Example DAST finding: SQL injection
Request:  GET /user?id=1&#x27; OR &#x27;1&#x27;=&#x27;1
Response: 500 Error + DB error message → Evidence of SQLi

IAST (Interactive)

Combines both: Instrumentation during runtime
Very good results, but complex to integrate

> Recommendation: SAST + DAST + manual penetration tests for maximum coverage

OWASP Top 10 - DAST Coverage

A01: Broken Access Control

Tests: Manipulating URL parameters (IDOR): /api/invoice/1234 → /api/invoice/1235 (third-party invoice?)
Tests: HTTP verb tampering (GET instead of POST for admin actions)

A02: Cryptographic Failures

Detects: HTTP instead of HTTPS on sensitive endpoints
Tests: Weak TLS cipher suites (SWEET32, POODLE)
Finds: Passwords/tokens in URLs or logs

A03: Injection

SQL Injection: ' OR 1=1--, UNION-based, Blind SQLi
OS Command Injection: ; ls -la
XPath Injection, LDAP Injection
Template Injection (SSTI): {{7*7}} → 49

A04: Insecure Design

Limited detectability (requires understanding of business logic)
Rate limiting missing → Brute force possible

A05: Security Misconfiguration

HTTP security headers missing (CSP, HSTS, X-Frame-Options)
Directory listing enabled
Debug mode active (stack traces, error messages with details)
Default credentials (admin/admin, admin/password)
Unnecessary HTTP methods (TRACE, PUT, DELETE)

A06: Vulnerable Components

Identify server headers → Version → CVE check
Example: Apache/2.4.49 → CVE-2021-41773 (Path Traversal)

A07: Authentication Failures

Brute Force Test (with Rate Limit Check)
Session Fixation
Password in URL

A08: Software and Data Integrity Failures

Deserialization Tests
CSRF token missing or too weak

A09: Security Logging Failures

Difficult to test automatically

A10: SSRF (Server-Side Request Forgery)

Payload: http://169.254.169.254/metadata (AWS IMDS)
Payload: http://localhost:8080/admin

DAST Tools Compared

Open Source

OWASP ZAP (Zed Attack Proxy):

Free, very powerful
Active and passive scan modes
CI/CD integration via Docker/CLI
GUI + API + CLI
Well-suited for: developer testing, CI/CD

# Basic scan
docker run -t ghcr.io/zaproxy/zaproxy:stable zap-baseline.py \
  -t https://app.example.com -r report.html

Nikto:

Simple server scanner
Finds: misconfigurations, outdated software, default files
Not suitable for in-depth application testing

docker run --rm hysnsec/nikto -h https://app.example.com

Nuclei (ProjectDiscovery):

Template-based, extremely fast
7,000+ templates for known CVEs
Good for: CVE scanning, misconfigurations

nuclei -u https://app.example.com -t cves/,misconfiguration/

Commercial Solutions

Burp Suite Pro (PortSwigger):

Industry standard for penetration testers
Active scanner + manual testing
Crawler with authentication support
Cost: ~€399/year

Invicti (formerly Netsparker):

DAST + IAST combination
Proof-based scanning (no false positives)
Enterprise-oriented

Tenable.io Web App Scanning:

Integration with Nessus workflow
Good for: combined infrastructure + application scans

StackHawk:

Developer-first DAST
Native GitHub Actions / GitLab CI support
Good for: DevSecOps, fast feedback loops

DAST in the CI/CD pipeline

# .github/workflows/dast.yml
name: DAST Security Scan

on:
  push:
    branches: [main, develop]

jobs:
  dast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Start application
        run: docker-compose up -d

      - name: Wait for app
        run: sleep 30

      - name: ZAP Baseline Scan
        uses: zaproxy/action-baseline@v0.12.0
        with:
          target: &#x27;http://localhost:8080&#x27;
          rules_file_name: &#x27;.zap/rules.tsv&#x27;
          cmd_options: &#x27;-a&#x27;

      - name: Upload ZAP Report
        uses: actions/upload-artifact@v4
        with:
          name: zap-report
          path: report_html.html

Scan Types for CI/CD

Baseline Scan (fast, ~2 min):

Passive scan (no active attack)
Missing security headers, default content, obvious errors
Ideal for: every push/PR

Full Scan (slow, ~30 min):

Active attack (SQLi, XSS, SSRF, etc.)
Only in staging environment!
Ideal for: release branches, daily nightly run

API Scan:

OpenAPI/Swagger spec as input
Automatically tests all API endpoints

zap-api-scan.py -t openapi.yaml -f openapi

Authenticated DAST Scans

Problem and Solution

> Problem: DAST without authentication only tests public pages. > Solution: Configure DAST with a login session.

ZAP with Form-Based Authentication

POST /login with username=test&amp;password=test
ZAP remembers session cookie / JWT token
All subsequent requests: authenticated

ZAP Context File for Complex Authentication

contexts:
  - name: &quot;MyApp&quot;
    urls:
      - &quot;https://app.example.com&quot;
    authentication:
      method: &quot;form&quot;
      loginUrl: &quot;https://app.example.com/login&quot;
      loginRequestData: &quot;username={%username%}&amp;password;={%password%}&quot;
    users:
      - name: &quot;testuser&quot;
        credentials:
          username: &quot;sectest@example.com&quot;
          password: &quot;TestPass123!&quot;

Important Notes

Create a separate test account (never use a production admin account!)
Test account with minimal privileges (standard user)
Separate test environment (never scan against production!)
Be mindful of rate limiting – DAST generates a lot of traffic

Embedding DAST in the SDLC

Secure Development Lifecycle

Phase	Measure
Development	SAST (real-time in IDE) + SAST (on every commit, CI)
Staging	DAST Baseline (on every deploy, ~2 min)
Staging	DAST Full Scan (daily, overnight)
Staging	Manual Penetration Test (quarterly)
Production	Passive DAST (monitoring, no active attack)
Production	External vulnerability scans (monthly)
Production	Bug bounty (when mature)

Categorization of Findings

Severity	Action
Critical	Immediate hotfix, no release
High	Fix in the next sprint (max. 7 days)
Medium	Fix in the sprint after next (max. 30 days)
Low	Backlog, quarterly review
Info	Document, no obligation to fix

DAST vs. SAST – Complement, Not a Replacement

SAST (Static Application Security Testing)

DAST (Dynamic Application Security Testing)

IAST (Interactive)

OWASP Top 10 - DAST Coverage

A01: Broken Access Control

A02: Cryptographic Failures

A03: Injection

A04: Insecure Design

A05: Security Misconfiguration

A06: Vulnerable Components

A07: Authentication Failures

A08: Software and Data Integrity Failures

A09: Security Logging Failures

A10: SSRF (Server-Side Request Forgery)

DAST Tools Compared

Open Source

Commercial Solutions

DAST in the CI/CD pipeline

Scan Types for CI/CD

Authenticated DAST Scans

Problem and Solution

ZAP with Form-Based Authentication

ZAP Context File for Complex Authentication

Important Notes

Embedding DAST in the SDLC

Secure Development Lifecycle

Categorization of Findings

AWARE7 Services on This Topic