Understanding DAST: Runtime Security Testing

Dynamic Application Security Testing (DAST) tests your application while it's running. Unlike SAST, which reads code, DAST interacts with your application like an attacker would.

How DAST Works

┌─────────────┐     HTTP Requests     ┌─────────────────┐
│ DAST Tool   │ ──────────────────▶  │ Running App     │
│ (ZAP, etc)  │                       │ (staging/test)  │
│             │ ◀──────────────────   │                 │
└─────────────┘     HTTP Responses    └─────────────────┘
       │
       ▼
┌─────────────┐
│  Report:    │
│  - XSS      │
│  - SQLi     │
│  - CSRF     │
└─────────────┘

DAST tools:

1. Crawl your application to discover endpoints
2. Inject malicious payloads into inputs
3. Analyze responses for vulnerability indicators
4. Report findings with proof-of-concept

DAST vs SAST Comparison

Aspect	SAST	DAST
When	Build time	Runtime
Input	Source code	Running application
Coverage	All code paths	Only accessible paths
False positives	Higher	Lower
Language dependent	Yes	No
Finds runtime issues	No	Yes
Configuration issues	Limited	Yes
Authentication bugs	Limited	Yes

What DAST Finds

Vulnerability	How DAST Detects It
SQL Injection	Sends ' OR 1=1-- and checks for database errors
XSS	Injects <script>alert(1)</script> and checks if executed
CSRF	Checks for missing CSRF tokens in forms
Open Redirects	Tests redirect parameters with external URLs
Security Headers	Checks for missing CSP, HSTS, X-Frame-Options
Information Disclosure	Looks for stack traces, version info in errors

Types of DAST Testing

1. Passive Scanning

Observes traffic without modifying requests:

• Checks security headers
• Identifies sensitive data exposure
• Finds information leakage

2. Active Scanning

Sends attack payloads to find vulnerabilities:

• SQL injection attempts
• XSS payload injection
• Path traversal attacks

3. API Scanning

Tests REST/GraphQL APIs:

• Authentication bypass
• Authorization flaws
• Injection in API parameters

When to Run DAST

Development ─────▶ Staging ─────▶ Production
                      │
                      ▼
               ┌─────────────┐
               │ DAST Scan   │
               │ (Nightly or │
               │  per-deploy)│
               └─────────────┘

Best practices:

• Run against staging, not production (unless passive only)
• Schedule nightly scans for comprehensive testing
• Run quick scans on every deployment
• Use authenticated scans to test protected areas

DAST in CI/CD

# GitHub Actions - DAST after deployment
dast:
  needs: deploy-staging
  runs-on: ubuntu-latest
  steps:
    - name: Wait for deployment
      run: sleep 30

    - name: DAST Scan
      uses: zaproxy/action-baseline@v0.10.0
      with:
        target: ${{ secrets.STAGING_URL }}
        fail_action: true  # Fail pipeline on high findings

DAST Limitations

Be aware of what DAST cannot do:

• Code-level issues: Can't see vulnerable code patterns
• Dead code: Can't test unreachable code paths
• Complex logic: Hard to test multi-step business logic
• Slow: Full scans take hours vs minutes for SAST
• Environment setup: Requires running application

Choosing DAST Approach

Scenario	Approach
Quick PR checks	Baseline scan (fast, common vulns)
Nightly builds	Full active scan
API testing	API-specific scan (Nuclei)
Compliance	Authenticated + unauthenticated

Next, we'll automate OWASP ZAP in your CI/CD pipeline. :::