03 - DAST - Dynamic Testing and Automated Penetration Testing

DAST: What is Dynamic Security Testing

DAST (Dynamic Application Security Testing) is an analysis technique that tests running applications by simulating real attacks from the outside. Unlike SAST which analyzes source code, DAST interacts with the application via HTTP as an attacker would, looking for vulnerabilities like XSS, SQL injection, CSRF, misconfiguration, and broken authentication.

DAST is a black-box approach: it has no access to the source code and sees the application exactly as a malicious user would. This complements SAST because it finds vulnerabilities that only emerge at runtime, such as configuration issues, missing HTTP headers, and insecure authentication flows.

In this article, we will explore OWASP ZAP and Burp Suite, their integration into CI/CD pipelines, and strategies for implementing automated DAST without slowing down the release cycle.

How DAST Works

A DAST tool follows a structured process to analyze a web application:

1. Spider/Crawl: the tool navigates the application discovering all pages, forms, and API endpoints
2. Passive Scan: analyzes HTTP responses looking for sensitive information, missing headers, insecure cookies
3. Active Scan: sends malicious payloads (SQL injection, XSS payloads, path traversal) and analyzes responses to identify vulnerabilities
4. Reporting: generates a report with found vulnerabilities, categorized by severity with remediation instructions

When to Use DAST in the Pipeline

DAST requires a running application, so it typically sits in the later stages of the pipeline:

• Staging environment: after deploying to staging, before promotion to production
• Pull Request: on ephemeral environments (preview deployments) for each PR
• Nightly scan: comprehensive scans scheduled every night on the staging environment
• Post-deploy: lightweight scan after each production deploy (passive scan only)

OWASP ZAP: The Open Source Standard

OWASP ZAP (Zed Attack Proxy) is the most widely used open source DAST tool in the world, maintained by the OWASP Foundation. It's free, extensible, and supports both manual use (as an interception proxy) and automated use (for CI/CD pipelines).

ZAP Baseline Scan in Docker

The simplest way to run an automated DAST scan is using ZAP's official Docker containers:

# Baseline scan: quick scan, passive checks only
docker run --rm -t ghcr.io/zaproxy/zaproxy:stable \
  zap-baseline.py \
  -t https://staging.myapp.com \
  -r zap-report.html \
  -J zap-report.json \
  -c zap-baseline.conf

# Full scan: complete scan with active scanning
docker run --rm -t ghcr.io/zaproxy/zaproxy:stable \
  zap-full-scan.py \
  -t https://staging.myapp.com \
  -r zap-full-report.html \
  -J zap-full-report.json

# API scan: specific for REST/GraphQL APIs
docker run --rm -t ghcr.io/zaproxy/zaproxy:stable \
  zap-api-scan.py \
  -t https://staging.myapp.com/api/openapi.json \
  -f openapi \
  -r zap-api-report.html
      

ZAP Configuration for CI/CD

To customize ZAP's behavior, a configuration file defines which rules to activate, severity thresholds, and exclusions:

# zap-baseline.conf
# Format: Rule_ID  WARN|IGNORE|FAIL
# Passive scan rules
10010   WARN    # Cookie No HttpOnly Flag
10011   WARN    # Cookie Without Secure Flag
10015   FAIL    # Incomplete or No Cache-control
10017   WARN    # Cross-Domain JavaScript Source
10020   FAIL    # X-Frame-Options Header
10021   FAIL    # X-Content-Type-Options Header
10038   FAIL    # Content Security Policy Header
10098   WARN    # Cross-Domain Misconfiguration
10202   WARN    # Absence of Anti-CSRF Tokens
90033   WARN    # Loosely Scoped Cookie
      

GitHub Actions Integration

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

jobs:
  dast:
    if: github.event.deployment_status.state == 'success'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: OWASP ZAP Baseline Scan
        uses: zaproxy/action-baseline@v0.12.0
        with:
          target: ${{ github.event.deployment_status.target_url }}
          rules_file_name: "zap-baseline.conf"
          cmd_options: "-a -j"
          fail_action: true

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

API Security Testing

Modern APIs (REST, GraphQL, gRPC) require a specific DAST approach. The most common API vulnerabilities include:

• Broken Object Level Authorization (BOLA): accessing other users' resources by modifying IDs
• Broken Authentication: weak JWT tokens, missing rate limiting, non-invalidated sessions
• Excessive Data Exposure: APIs returning more data than necessary
• Mass Assignment: modifying unintended fields through the request body
• Injection: SQL injection, NoSQL injection, command injection through API parameters

ZAP API Scan with OpenAPI

ZAP supports the OpenAPI specification to automatically generate tests for each endpoint:

# .github/workflows/api-dast.yml
name: API DAST Scan
on:
  workflow_dispatch:
  schedule:
    - cron: "0 2 * * 1-5"  # Every weeknight at 2:00 AM

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

      - name: ZAP API Scan
        uses: zaproxy/action-api-scan@v0.7.0
        with:
          target: "https://staging-api.myapp.com/openapi.json"
          format: openapi
          fail_action: true
          cmd_options: >
            -z "-config replacer.full_list(0).description=AuthHeader
            -config replacer.full_list(0).enabled=true
            -config replacer.full_list(0).matchtype=REQ_HEADER
            -config replacer.full_list(0).matchstr=Authorization
            -config replacer.full_list(0).replacement=Bearer TEST_TOKEN"
      

Fuzzing: Testing with Random Inputs

Fuzzing is a technique that sends random or semi-random inputs to the application to discover crashes, memory leaks, and unexpected behaviors. In the DAST context, fuzzing is particularly effective at finding:

• Buffer overflow in fields with unvalidated length
• Parsing errors with malformed input (corrupted JSON/XML/YAML)
• Race conditions with concurrent requests
• Denial of Service with large payloads

Burp Suite: The Professional Tool

Burp Suite by PortSwigger is the most widely used commercial DAST tool by professional penetration testers. The Community edition is free but limited; the Professional edition offers automated scanner, advanced intruder, and team collaboration.

Burp Suite excels at manual and semi-automated analysis, where the tester can intercept requests, modify them, and replay with custom payloads. For CI/CD integration, Burp Suite Enterprise offers REST APIs to launch scheduled scans.

Managing DAST Results

DAST results require a structured triage process to avoid false positives and prioritize fixes:

DAST for Single Page Applications (SPA)

Single Page Applications (Angular, React, Vue) present specific challenges for DAST: content is generated dynamically via JavaScript, and the traditional crawler might not explore all pages.

• ZAP's AJAX Spider: uses a headless browser to navigate SPAs and discover dynamic content
• Authentication: configure ZAP to handle JWT-based or SPA session logins
• Pre-seeding: provide ZAP with a list of URLs to test, extracted from the application build

DAST Best Practices

1. Dedicated environment: run DAST on an isolated staging environment, never directly in production
2. Realistic test data: populate the environment with realistic data to maximize coverage
3. Configured authentication: configure test credentials to explore authenticated areas
4. Incremental scans: baseline scans on PRs, full nightly scans
5. Correlation with SAST: correlate DAST findings with SAST findings to reduce duplicates
6. Quick feedback: immediately notify developers via Slack/Teams for critical findings

Conclusions

DAST is the essential complement to SAST in the DevSecOps strategy. While SAST finds vulnerabilities in source code, DAST verifies that the running application is actually secure, testing configurations, headers, authentication, and business flows.

In the next article, we'll explore SCA (Software Composition Analysis), the technique for analyzing open source dependencies and discovering known vulnerabilities in the libraries used by the project.

Related deep dive: 01 - Introduzione a DevSecOps - Shift-Left e Sicurezza nel Ciclo di Sviluppo.

Related deep dive: 02 - SAST - Analisi Statica del Codice e Rilevamento Vulnerabilità.