Dynamic Application Security Testing (DAST)

The Authentication Bypass SAST Never Found

February 14, 2021. Valentine's Day. The day someone sent us "love" in the form of a security disclosure.

Subject: "Your admin panel has no authentication on staging"

I laughed. Impossible. Our staging environment required authentication. I had implemented it myself.

Then I clicked the link: https://staging.example.com/admin?debug=true

My stomach dropped. Full admin access. No authentication required. A simple query parameter bypassed all auth checks.

The code:

// middleware/auth.ts
export function requireAuth(req, res, next) {
  // Skip auth in debug mode for easier testing
  if (req.query.debug === 'true') {
    return next();  // ❌ MASSIVE VULNERABILITY
  }
  
  // ... normal auth checks
}

This code had passed:

• ✅ SAST scans (no code-level vuln)

• ✅ Unit tests (debug mode worked as designed)

• ✅ Code review (looked reasonable for staging)

What failed? Nobody tested the running application with a security mindset.

That's what DAST does. It attacks your running application like a real attacker would, finding vulnerabilities that only appear at runtime.

This article documents how we integrated DAST into our pipeline and caught 47 runtime vulnerabilities that SAST never detected.

What You'll Learn

• DAST fundamentals and how it differs from SAST

• Integrating OWASP ZAP into CI/CD pipelines

• Authenticated scanning for protected endpoints

• Managing and prioritizing DAST findings

• DAST for APIs and microservices

• Performance optimization for fast feedback

What is DAST?

Dynamic Application Security Testing analyzes running applications by sending requests and analyzing responses—like an attacker would.

DAST Overview:

  How It Works:
    - Spider/crawl the application
    - Identify input points (forms, APIs, parameters)
    - Send attack payloads
    - Analyze responses for vulnerabilities
    - No access to source code
  
  What It Finds:
    - Authentication/authorization bypass
    - Session management issues
    - Server misconfigurations
    - SSL/TLS problems
    - Missing security headers
    - Clickjacking vulnerabilities
    - Actual exploitable XSS/SQLi (not just potential)
  
  What It Doesn't Find:
    - Code quality issues (use SAST)
    - Hard-coded secrets (use SAST)
    - Dependency vulnerabilities (use SCA)
    - Business logic flaws (mostly)
  
  When to Run:
    - After deployment to staging
    - Before production deployments
    - Scheduled scans (weekly)
    - After security incidents

SAST vs DAST Comparison

Key Insight: Use both. SAST finds potential issues in code; DAST confirms they're exploitable in production.

Setting Up DAST: OWASP ZAP

We use OWASP ZAP (Zed Attack Proxy) - free, open-source, powerful.

Basic ZAP Scan in GitLab CI/CD

# .gitlab-ci.yml
include:
  - template: Security/DAST.gitlab-ci.yml

variables:
  # Target staging environment
  DAST_WEBSITE: https://staging-${CI_COMMIT_REF_SLUG}.example.com
  
  # Authentication
  DAST_AUTH_URL: ${DAST_WEBSITE}/api/auth/login
  DAST_USERNAME_FIELD: "email"
  DAST_PASSWORD_FIELD: "password"
  DAST_USERNAME: ${DAST_TEST_USER}
  DAST_PASSWORD: ${DAST_TEST_PASSWORD}
  
  # Scan configuration
  DAST_FULL_SCAN_ENABLED: "false"  # Baseline scan by default
  DAST_SPIDER_MINS: 5
  DAST_TARGET_AVAILABILITY_TIMEOUT: 60

dast:
  stage: dast-scan
  needs: ["deploy-staging"]
  artifacts:
    reports:
      dast: gl-dast-report.json
    expire_in: 1 week
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      variables:
        DAST_FULL_SCAN_ENABLED: "true"  # Full scan on main
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      variables:
        DAST_FULL_SCAN_ENABLED: "false"  # Quick scan on MRs

Custom ZAP Scan with Docker

For more control, run ZAP directly:

# .gitlab-ci.yml
zap-baseline-scan:
  stage: dast-scan
  image: owasp/zap2docker-stable:latest
  variables:
    ZAP_TARGET: https://staging.example.com
  script:
    # Baseline scan (passive only, fast)
    - zap-baseline.py -t $ZAP_TARGET -r zap-baseline-report.html -J zap-report.json
  artifacts:
    paths:
      - zap-baseline-report.html
      - zap-report.json
    when: always
    expire_in: 1 week
  allow_failure: true  # Don't block on warnings
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

zap-full-scan:
  stage: dast-scan
  image: owasp/zap2docker-stable:latest
  variables:
    ZAP_TARGET: https://staging.example.com
  script:
    # Full scan (active attacks, comprehensive)
    - zap-full-scan.py -t $ZAP_TARGET -r zap-full-report.html -J zap-report.json
      -z "-config api.addrs.addr.name=.* -config api.addrs.addr.regex=true"
  artifacts:
    paths:
      - zap-full-report.html
      - zap-report.json
    when: always
    expire_in: 1 month
  allow_failure: false  # Block on critical findings
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  timeout: 2 hours  # Full scans take time

Authenticated Scanning

Most applications require authentication. ZAP needs to authenticate to test protected endpoints.

Method 1: Form-Based Authentication

# ZAP automation framework config
# zap-auth-config.yaml
env:
  contexts:
    - name: "staging-app"
      urls:
        - "https://staging.example.com"
      includePaths:
        - "https://staging.example.com/.*"
      excludePaths:
        - "https://staging.example.com/logout"
      
      authentication:
        method: "form"
        parameters:
          loginUrl: "https://staging.example.com/login"
          loginRequestData: "email={%username%}&password={%password%}"
        verification:
          method: "poll"
          pollFrequency: 60
          pollUnits: "requests"
          pollUrl: "https://staging.example.com/api/user"
          pollPostData: ""
      
      sessionManagement:
        method: "cookie"
        parameters: {}
      
      users:
        - name: "test-user"
          credentials:
            username: "${DAST_TEST_USER}"
            password: "${DAST_TEST_PASSWORD}"

Run with config:

zap-authenticated-scan:
  script:
    - |
      docker run --rm \
        -v $(pwd):/zap/wrk/:rw \
        -e DAST_TEST_USER=$DAST_TEST_USER \
        -e DAST_TEST_PASSWORD=$DAST_TEST_PASSWORD \
        owasp/zap2docker-stable:latest \
        zap-full-scan.py \
        -t https://staging.example.com \
        -n zap-auth-config.yaml \
        -r zap-report.html \
        -J zap-report.json

Method 2: JWT Token Authentication

For API-first applications:

#!/bin/bash
# scripts/zap-api-scan.sh

# 1. Get JWT token
TOKEN=$(curl -s -X POST https://staging.example.com/api/auth/login \
  -H "Content-Type: application/json" \
  -d '{"email":"'$DAST_TEST_USER'","password":"'$DAST_TEST_PASSWORD'"}' \
  | jq -r '.token')

# 2. Create ZAP config with token
cat > zap-api-config.yaml <<EOF
env:
  contexts:
    - name: "api-context"
      urls:
        - "https://staging.example.com/api"
      
      authentication:
        method: "scriptBasedAuthentication"
        parameters:
          script: |
            function authenticate(helper, paramsValues, credentials) {
              var msg = helper.prepareMessage();
              msg.setRequestHeader("Authorization", "Bearer $TOKEN");
              helper.sendAndReceive(msg);
              return msg;
            }
EOF

# 3. Run ZAP API scan
docker run --rm \
  -v $(pwd):/zap/wrk/:rw \
  owasp/zap2docker-stable:latest \
  zap-api-scan.py \
  -t https://staging.example.com/openapi.json \
  -f openapi \
  -n zap-api-config.yaml \
  -r zap-api-report.html \
  -J zap-api-report.json

Method 3: Session Cookie

If you have a long-lived session:

# Get session cookie from browser/Postman
SESSION_COOKIE="connect.sid=s%3A1234567890abcdef"

# Pass to ZAP
docker run --rm \
  -v $(pwd):/zap/wrk/:rw \
  owasp/zap2docker-stable:latest \
  zap-baseline.py \
  -t https://staging.example.com \
  -z "-config connection.defaultUserAgent='Mozilla/5.0' \
      -config replacer.full_list(0).description='Session' \
      -config replacer.full_list(0).enabled=true \
      -config replacer.full_list(0).matchtype='REQ_HEADER' \
      -config replacer.full_list(0).matchstr='Cookie' \
      -config replacer.full_list(0).replacement='$SESSION_COOKIE'"

Real Vulnerability Examples

Example 1: Authentication Bypass (The Valentine's Day Gift)

Vulnerability: Debug parameter bypasses authentication

// middleware/auth.ts (BEFORE)
export function requireAuth(req, res, next) {
  // ❌ Debug mode bypasses auth
  if (req.query.debug === 'true') {
    return next();
  }
  
  // Normal authentication
  const token = req.headers.authorization?.split(' ')[1];
  if (!token || !verifyToken(token)) {
    return res.status(401).json({ error: 'Unauthorized' });
  }
  
  next();
}

ZAP Finding:

Authentication Bypass Using Query Parameters

Risk: Critical
Confidence: High
URL: https://staging.example.com/admin?debug=true
Method: GET

Description:
  The application bypasses authentication when the 'debug' parameter 
  is set to 'true', allowing unauthorized access to admin functionality.

Evidence:
  Request:  GET /admin?debug=true
  Response: 200 OK
  Body: <h1>Admin Panel</h1>

  Request:  GET /admin
  Response: 401 Unauthorized

Attack:
  An attacker can access admin functionality without credentials by 
  adding ?debug=true to any URL.

CWE-306: Missing Authentication for Critical Function
CVSS: 9.8 (Critical)

Fixed Code:

// middleware/auth.ts (AFTER)
export function requireAuth(req, res, next) {
  // ✅ Debug mode only in development, with separate test accounts
  if (process.env.NODE_ENV === 'development' && req.query.debug === 'true') {
    // Still require authentication, just skip 2FA
    const token = req.headers.authorization?.split(' ')[1];
    if (!token || !verifyToken(token)) {
      return res.status(401).json({ error: 'Unauthorized' });
    }
    req.user = decodeToken(token);
    req.debugMode = true;
    return next();
  }
  
  // ✅ Production: Full authentication always required
  const token = req.headers.authorization?.split(' ')[1];
  if (!token || !verifyToken(token)) {
    return res.status(401).json({ error: 'Unauthorized' });
  }
  
  req.user = decodeToken(token);
  next();
}

Example 2: Insecure Direct Object Reference (IDOR)

Vulnerability: Users can access other users' orders

ZAP Finding:

Insecure Direct Object Reference

Risk: High
Confidence: Medium
URL: https://staging.example.com/api/orders/12345
Method: GET

Description:
  The application does not verify that the authenticated user has 
  permission to access the requested order. Users can view other 
  users' orders by changing the order ID.

Evidence:
  Authenticated as user_id=100:
  
  GET /api/orders/12345 (my order)
  → 200 OK, returns order data
  
  GET /api/orders/12346 (not my order)
  → 200 OK, returns OTHER USER's order data
  
  Authorization check is missing.

CWE-639: Authorization Bypass Through User-Controlled Key

Vulnerable Code:

// api/orders.controller.ts (BEFORE)
export async function getOrder(req: Request, res: Response) {
  const { orderId } = req.params;
  
  // ❌ No authorization check!
  const order = await db.query(
    'SELECT * FROM orders WHERE id = ?',
    [orderId]
  );
  
  res.json(order);
}

Fixed Code:

// api/orders.controller.ts (AFTER)
export async function getOrder(req: Request, res: Response) {
  const { orderId } = req.params;
  const userId = req.user.id;  // From JWT token
  
  // ✅ Verify user owns this order
  const order = await db.query(
    'SELECT * FROM orders WHERE id = ? AND user_id = ?',
    [orderId, userId]
  );
  
  if (!order) {
    return res.status(404).json({ error: 'Order not found' });
  }
  
  res.json(order);
}

Example 3: Missing Security Headers

ZAP Finding:

Missing Security Headers

Risk: Medium
Confidence: High
URL: https://staging.example.com

Missing Headers:
  ❌ Content-Security-Policy
  ❌ X-Content-Type-Options
  ❌ X-Frame-Options
  ❌ Strict-Transport-Security
  ❌ Permissions-Policy

Impact:
  - XSS attacks not mitigated
  - Clickjacking possible
  - MIME-sniffing attacks possible
  - Man-in-the-middle attacks easier

Fixed with Helmet.js:

// server.ts
import express from 'express';
import helmet from 'helmet';

const app = express();

// ✅ Apply comprehensive security headers
app.use(helmet({
  contentSecurityPolicy: {
    directives: {
      defaultSrc: ["'self'"],
      scriptSrc: ["'self'", "'unsafe-inline'", "https://cdn.example.com"],
      styleSrc: ["'self'", "'unsafe-inline'"],
      imgSrc: ["'self'", "data:", "https:"],
      connectSrc: ["'self'", "https://api.example.com"],
      fontSrc: ["'self'", "https://fonts.gstatic.com"],
      objectSrc: ["'none'"],
      mediaSrc: ["'self'"],
      frameSrc: ["'none'"],
    },
  },
  hsts: {
    maxAge: 31536000,  // 1 year
    includeSubDomains: true,
    preload: true
  },
  frameguard: {
    action: 'deny'  // Prevent clickjacking
  },
  noSniff: true,  // Prevent MIME-sniffing
  referrerPolicy: {
    policy: 'strict-origin-when-cross-origin'
  },
  permissionsPolicy: {
    features: {
      geolocation: ["'none'"],
      camera: ["'none'"],
      microphone: ["'none'"],
    }
  }
}));

Example 4: SSL/TLS Configuration Issues

ZAP Finding:

Weak SSL/TLS Configuration

Risk: Medium
Confidence: High
URL: https://staging.example.com

Issues Found:
  ❌ TLS 1.0 and TLS 1.1 enabled (deprecated)
  ❌ Weak cipher suites accepted
  ❌ Perfect Forward Secrecy not enforced

Recommended:
  ✅ TLS 1.2 and TLS 1.3 only
  ✅ Strong cipher suites only
  ✅ Enable HSTS

Fixed (Nginx):

# /etc/nginx/sites-available/app.conf
server {
    listen 443 ssl http2;
    server_name staging.example.com;
    
    # ✅ Modern SSL configuration
    ssl_certificate /etc/letsencrypt/live/staging.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/staging.example.com/privkey.pem;
    
    # ✅ TLS 1.2 and 1.3 only
    ssl_protocols TLSv1.2 TLSv1.3;
    
    # ✅ Strong ciphers with PFS
    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
    ssl_prefer_server_ciphers on;
    
    # ✅ HSTS
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
    
    # ✅ OCSP stapling
    ssl_stapling on;
    ssl_stapling_verify on;
    
    # ... rest of config
}

API Security Testing with ZAP

Modern applications are API-first. ZAP can scan APIs using OpenAPI/Swagger specs.

OpenAPI/Swagger Scan

# .gitlab-ci.yml
zap-api-scan:
  stage: dast-scan
  image: owasp/zap2docker-stable:latest
  script:
    # Generate OpenAPI spec from running app
    - curl https://staging.example.com/api-docs -o openapi.json
    
    # Scan using OpenAPI spec
    - zap-api-scan.py
      -t https://staging.example.com
      -f openapi
      -d openapi.json
      -r zap-api-report.html
      -J zap-api-report.json
      -z "-config replacer.full_list(0).description='Auth' \
          -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 $JWT_TOKEN'"
  artifacts:
    paths:
      - zap-api-report.html
      - zap-api-report.json
    expire_in: 1 week

GraphQL API Scan

#!/bin/bash
# scripts/zap-graphql-scan.sh

# 1. Get GraphQL schema
curl -X POST https://staging.example.com/graphql \
  -H "Content-Type: application/json" \
  -d '{"query": "query IntrospectionQuery { __schema { types { name } } }"}' \
  -o graphql-schema.json

# 2. Run ZAP with GraphQL support
docker run --rm \
  -v $(pwd):/zap/wrk/:rw \
  owasp/zap2docker-stable:latest \
  zap-api-scan.py \
  -t https://staging.example.com/graphql \
  -f graphql \
  -d graphql-schema.json \
  -r zap-graphql-report.html

Optimizing DAST Performance

DAST scans are slow. Our optimization strategies:

1. Scan Depth Configuration

# Fast scan for MRs (5-10 minutes)
zap-baseline-scan:
  variables:
    DAST_FULL_SCAN_ENABLED: "false"
    DAST_SPIDER_MINS: 2
    DAST_AJAX_SPIDER: "false"
  
# Comprehensive scan for main branch (30-60 minutes)
zap-full-scan:
  variables:
    DAST_FULL_SCAN_ENABLED: "true"
    DAST_SPIDER_MINS: 10
    DAST_AJAX_SPIDER: "true"

2. Scope Limiting

Only scan changed areas:

zap-scan:
  script:
    - |
      # Get changed files in MR
      CHANGED_ROUTES=$(git diff origin/$CI_MERGE_REQUEST_TARGET_BRANCH_NAME --name-only \
        | grep "src/api/" \
        | sed 's|src/api/||' \
        | sed 's|\.ts$||')
      
      # Build include URLs
      INCLUDE_URLS=""
      for route in $CHANGED_ROUTES; do
        INCLUDE_URLS="$INCLUDE_URLS -I https://staging.example.com/api/$route.*"
      done
      
      # Scan only changed routes
      zap-baseline.py -t https://staging.example.com $INCLUDE_URLS

3. Scheduled Comprehensive Scans

# .gitlab-ci.yml
zap-weekly-full-scan:
  stage: dast-scan
  image: owasp/zap2docker-stable:latest
  script:
    - zap-full-scan.py -t https://staging.example.com
      -r weekly-scan-report.html
  artifacts:
    paths:
      - weekly-scan-report.html
    expire_in: 1 month
  rules:
    - if: '$CI_PIPELINE_SOURCE == "schedule"'  # Weekly schedule
  timeout: 4 hours

Managing DAST Findings

Risk Prioritization

Priority Matrix:

  CRITICAL (Fix Immediately):
    - Authentication bypass
    - SQL injection (confirmed exploitable)
    - Remote code execution
    - Privilege escalation
    SLA: 24 hours
  
  HIGH (Fix This Sprint):
    - IDOR (data exposure)
    - XSS (confirmed)
    - CSRF on sensitive actions
    - Weak SSL/TLS
    SLA: 1 week
  
  MEDIUM (Fix This Month):
    - Missing security headers
    - Information disclosure (non-sensitive)
    - Session fixation
    SLA: 1 month
  
  LOW (Backlog):
    - Verbose error messages
    - Directory listing
    - Non-sensitive cookies without secure flag
    SLA: Best effort

Suppressing False Positives

# zap-false-positive-config.yaml
env:
  parameters:
    failOnError: true
    failOnWarning: false
    progressToStdout: true
  
  rules:
    - id: 10096  # Timestamp Disclosure
      action: "ignore"  # Not a security issue for us
      reason: "Timestamp disclosure is expected in our API responses"
    
    - id: 10015  # Re-examine Cache-control Directives
      action: "ignore"
      reason: "Static assets intentionally cached for performance"

Real Results

Findings (First 6 Months)

Initial DAST Scan (March 2021):
  Total Findings: 127
    Critical: 3 (auth bypass, SQLi, XXE)
    High: 18
    Medium: 47
    Low: 59
  Time to Remediate: 3 months

Current (Nov 2023):
  Total Findings: 8
    Critical: 0  ✅
    High: 0   ✅
    Medium: 8
    Low: 0
  Average Scan Time: 12 minutes

Impact

Prevented Incidents:
  - Authentication bypass (could have been P0 incident)
  - IDOR exposing 2.4M user records
  - SQLi in payment processing
  
Estimated Savings: $1.5M in prevented breaches
DAST Tooling Cost: $0 (open source)
ROI: Infinite

Key Takeaways

✅ DAST finds runtime vulnerabilities SAST can't detect ✅ Authenticated scanning essential - most vulnerabilities behind login ✅ Combine SAST + DAST for comprehensive coverage ✅ Optimize scan depth - fast scans for MRs, comprehensive for main ✅ API scanning critical for microservices architectures ✅ Security headers easy to fix, high impact ✅ Run DAST in staging - never scan production without permission

What's Next

SAST finds code-level issues. DAST finds runtime issues. But what about the hybrid approach? The next article covers IAST (Interactive Application Security Testing) and Runtime Application Self-Protection (RASP)—security testing that combines the best of both worlds.

---

Next Article: IAST and Runtime Protection →

---

Part of the DevSecOps 101 Series