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.htmlAPI 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.htmlFull 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.htmlCI 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.htmlAuthenticated 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.htmlFor 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: TestPassword123Tuning 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 applicableWhat 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:
- Configure your browser to proxy through Burp (127.0.0.1:8080)
- Browse the application normally — Burp records every request
- Right-click any request and "Send to Intruder" or "Send to Repeater"
- 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/1GitHub 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:latestBurp 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.netWhen 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 attemptsThese 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:
- Auto-fail on confirmed High/Critical findings — blocked the PR until resolved
- Review Medium findings — confirm manually, suppress if false positive, file bug if real
- 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.