DAST Testing Guide: OWASP ZAP vs Burp Suite for Automated API Scanning

DAST Testing Guide: OWASP ZAP vs Burp Suite for Automated API Scanning

Dynamic Application Security Testing (DAST) probes your running application for vulnerabilities — sending real HTTP requests and observing how the server responds. OWASP ZAP and Burp Suite are the two most widely used tools. This guide covers what each finds, how to automate scans in CI, and how to interpret the results.

Key Takeaways

DAST finds what SAST misses. Runtime configuration, server headers, WAF bypass, and authentication flaws only appear when the app is running.

ZAP is free and CI-friendly. The ZAP Docker image runs in any pipeline with zero cost. Baseline and full scans are one-command operations.

Burp Suite Pro is best for manual-plus-automated workflows. Its Intruder and Scanner are the industry standard for pen testers, but automation requires scripting the REST API.

Always authenticate before scanning. An unauthenticated scan misses every vulnerability behind a login wall — which is most of your application.

Tune down noise before acting on results. Both tools produce false positives. Confirm findings manually before filing security bugs.

What Is DAST?

Dynamic Application Security Testing sends HTTP requests to a running application and analyzes responses to find vulnerabilities. Unlike SAST (which reads source code), DAST treats the application as a black box — the same way an attacker would.

DAST excels at finding:

  • Injection flaws that manifest at runtime (SQL, XSS, command injection)
  • Security misconfigurations (missing headers, open CORS policies)
  • Authentication and session management weaknesses
  • Server-side request forgery (SSRF) via response analysis
  • Broken access control (accessing resources as wrong user)

DAST cannot find:

  • Vulnerabilities in code paths the scanner never triggers
  • Logic flaws that require domain knowledge to exploit
  • Client-side vulnerabilities in JavaScript that don't reach the server

OWASP ZAP

OWASP ZAP (Zed Attack Proxy) is the most widely used open-source DAST tool. Maintained by OWASP, it's available as a desktop application, CLI, and Docker image — and it's entirely free.

ZAP Scan Modes

ZAP offers three scan modes relevant to CI/CD:

Baseline Scan — Spiders the target passively, no active attacks. Safe to run against production.

docker run -t ghcr.io/zaproxy/zaproxy:stable zap-baseline.py \
  -t https://api.example.com \
  -r baseline-report.html

API Scan — Imports an OpenAPI/Swagger spec and scans all defined endpoints actively.

docker run -v $(pwd):/zap/wrk/:rw \
  ghcr.io/zaproxy/zaproxy:stable zap-api-scan.py \
  -t /zap/wrk/openapi.yaml \
  -f openapi \
  -r api-scan-report.html

Full Scan — Active scanning with spider + attack. Use only against staging/dev environments.

docker run -t ghcr.io/zaproxy/zaproxy:stable zap-full-scan.py \
  -t https://staging.example.com \
  -r full-scan-report.html

CI Integration with GitHub Actions

# .github/workflows/zap-scan.yml
name: ZAP API Scan
on:
  push:
    branches: [main]

jobs:
  zap-scan:
    runs-on: ubuntu-latest
    services:
      app:
        image: your-app:latest
        ports:
          - 3000:3000
    steps:
      - uses: actions/checkout@v4

      - name: Run ZAP API Scan
        uses: zaproxy/action-api-scan@v0.7.0
        with:
          target: 'http://localhost:3000'
          format: openapi
          api_scan_rules_file_name: .zap/rules.tsv
          fail_action: true

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

Authenticated Scanning

By default, ZAP scans as an unauthenticated user. For anything behind a login, provide an auth header:

docker run -t ghcr.io/zaproxy/zaproxy:stable zap-api-scan.py \
  -t /zap/wrk/openapi.yaml \
  -f openapi \
  -H "Authorization: Bearer eyJhbGciOiJSUzI1NiJ9..." \
  -r report.html

For form-based authentication, use ZAP's context files to define login sequences:

# zap-auth-context.yaml
authentication:
  method: form
  loginPageUrl: https://app.example.com/login
  loginRequestData: username={%username%}&password={%password%}
  usernameParameter: username
  passwordParameter: password
users:
  - name: testuser
    credentials:
      username: test@example.com
      password: TestPassword123

Tuning False Positives

ZAP produces false positives — especially for informational findings. Use a rules file to suppress known-false alerts:

# .zap/rules.tsv
# RULE_ID	ALERT_THRESHOLD	ATTACK_STRENGTH
10016	OFF	DEFAULT  # Web Browser XSS Protection - informational
10020	OFF	DEFAULT  # X-Frame-Options - handled by CDN
90003	LOW	DEFAULT  # Sub Resource Integrity - not applicable

What ZAP Reports

A typical ZAP scan report shows:

  • High: SQL injection, command injection, file inclusion
  • Medium: CSRF, missing security headers, CORS misconfiguration
  • Low: Cookie flags, information disclosure, server version
  • Informational: Modern web application headers, user-controllable content

Burp Suite

Burp Suite Pro is the standard tool for professional penetration testers. It combines a proxy, active scanner, Intruder (fuzzer), Repeater (request editor), and Decoder in one interface. The Community edition is free but lacks the active scanner — making it primarily a manual testing tool.

Burp Scanner vs Manual Testing

Burp Scanner (Pro only) actively crawls and attacks the target. It understands JavaScript-heavy single-page applications, follows multi-step workflows, and generates detailed issue reports with evidence.

Manual workflows are where Burp excels regardless of edition:

  1. Configure your browser to proxy through Burp (127.0.0.1:8080)
  2. Browse the application normally — Burp records every request
  3. Right-click any request and "Send to Intruder" or "Send to Repeater"
  4. Use Intruder to fuzz parameters with payloads from the Burp payload library

Automating Burp in CI

Burp Pro exposes a REST API. The typical CI pattern uses burp-rest-api:

# Start Burp with REST API enabled
java -jar burpsuite_pro.jar \
  --unpause-spider-and-scanner \
  --config-file=burp-project.json \
  --user-config-file=burp-user.json \
  -Xmx1G

<span class="hljs-comment"># Trigger a scan via API
curl -X POST http://localhost:1337/v0.1/scan \
  -H <span class="hljs-string">"Content-Type: application/json" \
  -d <span class="hljs-string">'{"urls": ["https://staging.example.com"], "scan_configuration": []}'

<span class="hljs-comment"># Poll for completion
curl http://localhost:1337/v0.1/scan/1

GitHub Actions example using the unofficial burp-ci-scanner image:

- name: Burp Suite Scan
  run: |
    docker run --rm \
      -e BURP_PRO_LICENSE=${{ secrets.BURP_PRO_LICENSE }} \
      -e TARGET_URL=https://staging.example.com \
      portswigger/burp-suite-enterprise-scanning:latest

Burp Extensions for API Testing

Burp's BApp Store includes extensions for API security:

  • OpenAPI Parser — imports Swagger/OpenAPI specs and populates the site map
  • AuthMatrix — tests access control by replaying requests as different users
  • Param Miner — discovers hidden HTTP parameters and headers
  • JWT Editor — manipulates JWT tokens (alg:none attacks, key confusion)
  • Turbo Intruder — high-speed fuzzing for race conditions and rate limit testing

Burp Collaborator

Burp Collaborator is Burp's out-of-band (OOB) testing service. It provides a unique subdomain (burp-collab.net) that logs DNS and HTTP callbacks. This enables detection of:

  • Blind SSRF (no response visible, but DNS lookup happens)
  • Blind SQL injection with out-of-band exfiltration
  • Blind XXE with HTTP callback
# Burp auto-injects Collaborator payloads like:
https://your-unique-id.burpcollaborator.net

When the server hits this URL during processing — even if nothing is returned — Burp logs the interaction, proving the vulnerability.


ZAP vs Burp Suite Comparison

Feature OWASP ZAP Burp Suite Pro
Price Free (open source) $449/year/user
CI integration Docker, official Actions REST API, scripts
Active scanner Yes Yes (superior)
Manual proxy Yes Yes (superior)
OOB testing No Yes (Collaborator)
API import OpenAPI, SOAP OpenAPI, SOAP
SPA support Limited Good
Custom scripts Python, Ruby Java, Python
Community Large (OWASP) Large (PortSwigger)
Reporting HTML, JSON, XML HTML, XML

Building a DAST Pipeline

A practical DAST pipeline for an API service looks like this:

graph LR
    A[Push to main] --> B[Deploy to staging]
    B --> C[Run ZAP API scan]
    C --> D{Findings?}
    D -->|High severity| E[Fail pipeline]
    D -->|Medium/Low| F[Upload report, pass]
    E --> G[Security team reviews]

Implementation:

# .github/workflows/security.yml
name: Security Scan
on:
  push:
    branches: [main]

jobs:
  deploy-staging:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./scripts/deploy-staging.sh

  dast-scan:
    needs: deploy-staging
    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.example.com
          format: openapi
          fail_action: true
          cmd_options: '-a -j -l WARN'

      - name: Upload Results
        uses: actions/upload-artifact@v4
        if: failure()
        with:
          name: zap-findings
          path: '*.html'

Combining DAST with Functional Tests

DAST scanners don't understand your application's workflow. A scanner won't add an item to a cart, apply a coupon, then check the order total — but your application's security depends on that sequence working correctly.

HelpMeTest fills this gap. Write business-logic security tests in plain English that verify authorization, data isolation, and workflow integrity:

*** Test Cases ***
User Cannot Access Other User's Orders
    As  UserA
    Go To  https://app.example.com/orders/12345
    # Order 12345 belongs to UserB
    Page Should Contain  403
    Page Should Not Contain  UserB's Order

Rate Limiting Enforced on Login
    FOR  ${i}  IN RANGE  10
        Go To  https://app.example.com/login
        Input Text  id=email  attacker@example.com
        Input Text  id=password  WrongPassword${i}
        Click Button  id=login-btn
    END
    Page Should Contain  Too many attempts

These tests run alongside ZAP in your CI pipeline — covering what automated scanners miss.

Interpreting Scan Results

Both tools produce more findings than you should act on immediately. A practical triage workflow:

  1. Auto-fail on confirmed High/Critical findings — blocked the PR until resolved
  2. Review Medium findings — confirm manually, suppress if false positive, file bug if real
  3. Track Low/Informational in backlog — schedule periodic review, not immediate action

Most scan findings in the first run are:

  • Missing HTTP security headers (Content-Security-Policy, HSTS, X-Frame-Options) — fix once, suppress after
  • Cookie flags (HttpOnly, Secure, SameSite) — usually a one-line config change
  • Server version disclosure — configure your web server to suppress it

These are real issues, but they're not the SQL injection and auth bypass bugs that need immediate attention.

Conclusion

OWASP ZAP and Burp Suite are complementary tools. Use ZAP for automated CI scanning — it's free, Docker-native, and integrates in minutes. Use Burp for manual pen testing and deeper investigation of specific endpoints. Neither replaces a skilled penetration tester for critical systems, but both dramatically improve your baseline security posture when run consistently.

The key is consistency: a ZAP scan on every push to main catches regressions before they reach production. Combined with SAST tools like Semgrep and runtime tests in HelpMeTest, you get defense in depth across all stages of your development lifecycle.

Read more