Dynamic analysis (DAST) — fuzzing, scanning a running application

DAST (Dynamic Application Security Testing) tests the application while it runs. Instead of reading source code, the scanner sends real requests and observes responses — the same way an attacker would. This reveals problems that only appear at runtime: misconfigurations, missing headers, unexpected behaviors.

DAST vs SAST

SAST                          DAST
─────────────────────         ──────────────────────
Reads source code             Interacts with running app
Runs without deploy           Requires active environment
Finds: taint paths,           Finds: misconfig, runtime
  SQL injection in code         XSS, auth bypass
Higher false positive rate    More concrete results
Fast in CI                    Slower, requires infrastructure

Common Tools

Tool	Type	Use
OWASP ZAP	OSS web scanner	CI/CD, manual exploration
Nikto	OSS web scanner	Quick reconnaissance
Burp Suite	Proxy + scanner	Assisted manual pentest
sqlmap	SQLi specialist	Authorized environments only
ffuf / wfuzz	HTTP fuzzer	Endpoint discovery

Basic Scan with OWASP ZAP

ZAP has a CLI mode for automation:

# Using Docker — points to test environment (never production)
docker run -t owasp/zap2docker-stable zap-baseline.py \
  -t http://staging.example.com \
  -r zap-report.html

# Typical output
WARN-NEW: Web Cache Deception [10056] x 1
WARN-NEW: Missing Anti-clickjacking Header [10020] x 4
FAIL-NEW: SQL Injection [40018] x 1

-r generates an HTML report. FAIL indicates critical findings configurable as a CI gate.

REST API Fuzzing

Fuzzing sends malformed or unexpected inputs to discover anomalous behavior:

# ffuf — parameter fuzzing on a test endpoint
ffuf -w /wordlists/payloads.txt \
     -u "http://staging.example.com/api/user?id=FUZZ" \
     -fc 200 \
     -o results.json

# Watch for: 500 responses (internal error), timeouts, differing response sizes

Common fuzzing payloads:

• Very long strings (buffer overflow)
• Special characters: ' " ; < > & | \
• Boundary values: 0, -1, 2147483648, null
• Path traversal: ../../../etc/passwd
• Classic injections: ' OR 1=1--

Never point fuzzing tools at production or unauthorized systems.

Authentication in DAST

Many pages require login. ZAP and Burp support authenticated sessions:

# ZAP automation framework — form-based auth
authentication:
  method: form
  loginUrl: http://staging.example.com/login
  loginRequestData: "username={%username%}&password={%password%}"
  usernameField: username
  passwordField: password

Without authentication, the scanner only sees the public surface of the application.

CI/CD Integration

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

on:
  push:
    branches: [staging]

jobs:
  zap-scan:
    runs-on: ubuntu-latest
    steps:
      - name: ZAP Baseline Scan
        uses: zaproxy/action-baseline@v0.12.0
        with:
          target: 'http://staging.example.com'
          fail_action: true
          cmd_options: '-l WARN'

Run DAST only against staging environments with fake data — never production.

DAST Limitations

• Does not access internal logic — tests only the HTTP surface.
• Can be slow for large applications (hours for a full scan).
• Generates real traffic: may trigger monitoring alerts or affect environment performance.
• Coverage depends on the ability to navigate the application (SPAs require extra configuration).

DAST complements SAST. Together they cover both code analysis and runtime behavior.