DAST - Dynamic Application Security Testing

DAST vs. SAST - Key Differences

Property	DAST (Dynamic)	SAST (Static)
When it tests	Runtime - the application must be running	Build time - static code analysis
Code access	Black-box - does not require source code	White-box - requires access to code
What it detects	Runtime vulnerabilities, configuration and deployment issues	Coding errors, unsafe patterns, potential vulnerabilities
False positives	Low - tests actual behavior	Higher - may flag safe code
Speed	Slower (hours for large applications)	Faster (minutes)
Vulnerability types	SQL injection, XSS, CSRF, auth issues, SSRF	Buffer overflows, race conditions, unsafe functions
Language	Language-agnostic (tests HTTP API)	Language-specific (Java, C#, Python...)
SDLC phase	QA, Staging, Pre-production	Development, PR reviews

Best Practice: Combine SAST + DAST

You achieve the best results by combining both approaches. SAST reveals potential problems in code during development, while DAST verifies whether these vulnerabilities are exploitable in a real environment. This strategy is called "Defense in Depth" and covers both theoretical and practical security gaps.

How DAST Works

Typical DAST Scan Workflow

1

Crawling (Spider) The scanner browses the application like a regular user, mapping all pages, forms, parameters, and endpoints

2

Attack Surface Mapping Identifies entry points (input fields, URL params, headers, cookies) where it can perform tests

3

Fuzzing & Injection Sends malicious payloads (SQL injection, XSS, command injection) to all entry points

4

Response Analysis Analyzes HTTP responses, error messages, and timing patterns to detect vulnerabilities

5

Vulnerability Confirmation Verifies false positives and generates a detailed report with PoC (Proof of Concept)

6

Reporting Creates a prioritized list of vulnerabilities with CVSS scores, remediation steps, and reproduction instructions

What DAST Detects

1. Injection Attacks

SQL Injection: Manipulation of database queries through user input
Command Injection: Execution of OS commands through unsanitized input
LDAP/XML/XPath Injection: Injection into specific query languages
Template Injection: SSTI (Server-Side Template Injection)

2. Cross-Site Scripting (XSS)

Reflected XSS: Malicious script in URL/parameter reflected back to the user
Stored XSS: Persistent XSS stored in the database
DOM-based XSS: Client-side XSS through JavaScript manipulation

3. Authentication and Session Management

Broken Authentication: Weak passwords, session hijacking, credential stuffing
Session Fixation: Attacker fixes the victim's session ID
Insecure Session Cookies: Missing Secure/HttpOnly/SameSite flags
JWT Vulnerabilities: Weak signing, algorithm confusion

4. Broken Access Control

IDOR (Insecure Direct Object References): Accessing other users' objects by changing the ID
Path Traversal: Accessing files outside webroot (../../../etc/passwd)
Privilege Escalation: Regular user gains admin privileges
Missing Function Level Access Control: API endpoints without authorization

5. Security Misconfiguration

Verbose Error Messages: Stack traces revealing internal information
Default Credentials: Admin/admin, root/root
Directory Listing: Visible directory structures
Missing Security Headers: CSP, HSTS, X-Frame-Options
Exposed Admin Panels: /admin, /phpmyadmin, /wp-admin without protection

6. Other Runtime Vulnerabilities

CSRF (Cross-Site Request Forgery): Unauthorized actions on behalf of a user
SSRF (Server-Side Request Forgery): Server makes a request to an attacker-chosen target
XXE (XML External Entity): Reading files through the XML parser
Insecure Deserialization: RCE through deserialization of untrusted data
Business Logic Flaws: Race conditions, price manipulation

Popular DAST Tools

Open Source / Free

OWASP ZAP (Zed Attack Proxy)

The most popular open-source DAST tool. Ideal for beginners and professionals alike, with both GUI and CLI modes.

Active and passive scanning
Intercepting proxy for manual testing
Spidering and automatic crawling
API scan (REST, GraphQL, SOAP)
CI/CD integration (Docker, Jenkins, GitLab)
1000+ security checks

Commercial / Freemium

Burp Suite Professional

Industry-standard penetration testing platform with advanced features for both manual and automated testing.

Burp Scanner - automated vulnerability scanner
Intruder - advanced fuzzing engine
Repeater - request manipulation
Collaborator - out-of-band detection (SSRF, XXE)
Extensions (BApp Store)
$449/year for Professional license

Open Source

Nuclei

A modern fast vulnerability scanner based on YAML templates. Ideal for CI/CD automation.

4000+ community templates
Fast parallel scanning
Custom templates in YAML
Integration with Slack, Jira, GitHub
Headless browser support

Commercial SaaS

Acunetix

Enterprise-grade web vulnerability scanner focused on complex JavaScript applications.

Advanced JavaScript/SPA crawling
Network security scanning
Integration with WAF (Web Application Firewall)
Issue tracking (Jira, GitHub)

Open Source

Nikto

A classic web server scanner for detecting known vulnerabilities and misconfigurations.

7000+ potentially dangerous files/programs
Outdated server versions detection
Server misconfigurations
Fast, lightweight CLI tool

Cloud / API-focused

StackHawk

A modern DAST platform focused on API security and a developer-first workflow.

OpenAPI/Swagger integration
GraphQL endpoint testing
CI/CD native (GitHub Actions, GitLab CI)
Developer-friendly reporting
Shift-left DAST approach

Practical Example: OWASP ZAP in CI/CD

Integrating OWASP ZAP into a GitLab CI/CD pipeline:

# .gitlab-ci.yml
stages:
  - build
  - test
  - security
  - deploy

# DAST scan using OWASP ZAP
dast_scan:
  stage: security
  image: owasp/zap2docker-stable
  variables:
    TARGET_URL: "https://staging.example.com"
  script:
    # Baseline scan (passive + spider)
    - zap-baseline.py -t $TARGET_URL -r zap-report.html -J zap-report.json

    # Full scan (active attacks) - can be used for staging
    # - zap-full-scan.py -t $TARGET_URL -r zap-report.html -J zap-report.json

    # API scan with OpenAPI spec
    # - zap-api-scan.py -t $TARGET_URL -f openapi -r api-report.html
  artifacts:
    reports:
      # GitLab Security Dashboard integration
      sast: zap-report.json
    paths:
      - zap-report.html
    expire_in: 1 week
  allow_failure: false  # Block deployment if critical issues found
  only:
    - merge_requests
    - main
                    

GitHub Actions Example

name: DAST Scan

on:
  push:
    branches: [ main, staging ]
  pull_request:
    branches: [ main ]

jobs:
  zap_scan:
    runs-on: ubuntu-latest
    name: OWASP ZAP Scan
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Deploy to staging
        run: |
          # Deploy application to staging for testing
          docker-compose up -d
          sleep 30  # Wait for application startup

      - name: ZAP Baseline Scan
        uses: zaproxy/action-baseline@v0.7.0
        with:
          target: 'http://localhost:3000'
          rules_file_name: '.zap/rules.tsv'
          cmd_options: '-a'

      - name: Upload ZAP Report
        uses: actions/upload-artifact@v3
        if: always()
        with:
          name: zap-scan-report
          path: report_html.html

      - name: Fail build on high severity
        run: |
          # Parse JSON report and fail if critical/high
          HIGH_COUNT=$(jq '.site[0].alerts | map(select(.riskcode >= 2)) | length' report_json.json)
          if [ "$HIGH_COUNT" -gt 0 ]; then
            echo "Found $HIGH_COUNT high/critical vulnerabilities!"
            exit 1
          fi
                    

Docker Compose for Local DAST Testing

# docker-compose.yml
version: '3.8'

services:
  app:
    build: .
    ports:
      - "3000:3000"
    environment:
      NODE_ENV: test
      DATABASE_URL: postgres://user:pass@db:5432/testdb

  db:
    image: postgres:15
    environment:
      POSTGRES_PASSWORD: pass
      POSTGRES_DB: testdb

  zap:
    image: owasp/zap2docker-stable
    command: zap-baseline.py -t http://app:3000 -r /zap/wrk/report.html
    volumes:
      - ./zap-reports:/zap/wrk
    depends_on:
      - app

# Usage:
# docker-compose up -d app db
# docker-compose run zap
# Report will be in ./zap-reports/report.html
                    

DAST Best Practices

Recommended Practices

Test on staging/QA, not on production: DAST can cause DOS, data corruption, or trigger alarms
Use test credentials: Dedicated test accounts for authenticated scanning
Rate limiting awareness: DAST generates many requests; you may be blocked by WAF/CDN
Baseline vs Full scan: Baseline for every PR, Full scan weekly or before release
Custom scan policies: Disable tests that are not relevant (e.g., CMS scan for an API-only app)
Authentication context: Configure ZAP/Burp for the login workflow; test authenticated areas
API specification: Use OpenAPI/Swagger specs for better coverage of API endpoints
False positive management: Review and mark FPs; create whitelists
Trend tracking: Monitor the number of vulnerabilities over time, not just the current state
SIEM integration: Send DAST findings to a centralized security dashboard

Common DAST Mistakes

Running DAST on production: Can cause outages, corrupt data, or false alarms
Insufficient crawling scope: Scanner fails to find all endpoints (especially with SPAs)
Ignoring false positives: Teams lose trust in the tool
Automated scans only: Manual pentesting finds business logic flaws that DAST cannot detect
No authentication: 80% of the application is behind login; scanning only the homepage is insufficient
One scan = done: DAST should run continuously, not just before release
Outdated scanners: New CVEs and attack vectors require fresh vulnerability checks

DAST for Different Application Types

1. REST API

# OWASP ZAP API scan with OpenAPI spec
zap-api-scan.py \
  -t https://api.example.com/v1 \
  -f openapi \
  -d api-spec.yaml \
  -r api-security-report.html \
  -J api-report.json \
  -x api-xml-report.xml

# Postman Collection import into ZAP
# 1. Export Postman collection
# 2. Import into ZAP as "context"
# 3. Run Active Scan on imported endpoints
                    

2. GraphQL API

# Escape GraphQL Security Scanner
npm install -g @escape.tech/graphql-armor

# Introspection query for schema mapping
curl -X POST https://api.example.com/graphql \
  -H "Content-Type: application/json" \
  -d '{"query": "{__schema{types{name fields{name}}}}"}'

# ZAP GraphQL plugin
# Automatically detects GraphQL endpoints and tests:
# - Depth limit bypass
# - Batching attacks
# - Introspection exposure
# - Mutation authorization
                    

3. Single Page Applications (SPA)

# ZAP with headless browser for React/Vue/Angular apps
zap.sh -daemon -config api.disablekey=true -config spider.maxDuration=60

# Use Ajax Spider instead of traditional spider
# Ajax Spider uses Selenium for JavaScript rendering
curl -X POST \
  'http://localhost:8080/JSON/ajaxSpider/action/scan/?url=https://app.example.com'

# Or Nuclei with headless mode
nuclei -u https://app.example.com \
  -headless \
  -t ~/nuclei-templates/ \
  -o spa-scan-results.txt
                    

DAST vs IAST vs RASP

Tool	How It Works	Advantages	Disadvantages
DAST (Dynamic)	Black-box testing of a running application from the outside	No code access needed, language-agnostic, low false positives	Slow, does not pinpoint exact code location, requires a running application
SAST (Static)	Source code analysis without execution	Fast, early detection, exact code location	Higher false positives, language-specific, cannot see runtime issues
IAST (Interactive)	Agent inside the application monitoring runtime behavior	Accurate, low FP, code-level insights + runtime context	Requires instrumentation, performance overhead
RASP (Runtime Protection)	Active defense in production - blocks attacks in real time	Production security, zero-day protection, virtual patching	Performance impact, false positives can block legitimate users