10 min read · 1,975 words

Educational & Ethical Use Only — This article is provided for educational and ethical cybersecurity research purposes only. The techniques described should only be used on systems you own or have explicit permission to test. Always follow responsible disclosure and the laws applicable to you. Mitigations are included so engineers can harden real systems.

Break Your Own API with DAST: OWASP ZAP Scans and Authenticated API Testing Lab

Yes—you can break your own API in under an hour. ZAP’s HTTP proxy, OpenAPI importer, and authentication-enabled active scan will surface injection flaws, broken authentication, error leakage, and unrestricted resource consumption in a deliberately vulnerable test API. This lab walks you through the complete workflow, from Docker setup to CI-ready automation.

TL;DR: Yes, You Can Break Your Own API with ZAP in Under an Hour

ZAP is not just a web app scanner with an API bolted on. With a context, a session handling rule, and an auth strategy configured, OWASP ZAP runs authenticated dynamic scans that map directly to OWASP API Security Top 10 categories—API1 through API10. Point it at crAPI or VAmPI, import the OpenAPI spec, seed the auth token, fire the active scan, and you’ll have real findings to triage before your coffee gets cold. Some flaws—BOLA, business logic—will slip past it, and knowing that boundary is half the job.

What DAST Does and Doesn’t Catch in APIs

Traditional DAST grew up crawling HTML. It followed links, submitted forms, and matched regexes against responses. APIs broke that model: no links, JSON instead of markup, and—critically—nearly every meaningful endpoint hides behind authentication. A scanner that can’t log in is scanning an empty building.

Dynamic analysis tests the running application from the outside: send requests, observe responses. Static analysis (SAST) reads source code. DAST finds what actually manifests at runtime—misconfigured headers, injection behavior, verbose errors—but it can’t see dead code paths, weak crypto in an unused library, or logic that only breaks under specific business conditions. The two approaches are complementary; neither substitutes for the other. CISA’s secure-by-design guidance and OWASP’s API Security Top 10 (2023) both emphasize layered testing precisely because no single tool covers the surface.

Set expectations for false positives now. ZAP’s alerts ship with confidence levels, and API scanning produces its share of low-confidence noise—especially around reflections that don’t actually execute. You’ll triage; that’s the job.

Lab Setup: Vulnerable API, ZAP, and a Throwaway Environment

You need three things: a vulnerable target, ZAP, and isolation.

Target: crAPI (the OWASP-backed “completely ridiculous API”) or VAmPI, a lightweight vulnerable API built on Flask with an OpenAPI spec included. Both are Docker-native.
Scanner: ZAP from the official download, or—better for repeatability—the zaproxy/zap-stable Docker image.
Isolation: Run everything inside a local Docker network or VM. Only scan APIs you own. Scanning third-party APIs without authorization is illegal in most jurisdictions regardless of intent—treat authorization as a prerequisite, not a formality.

Pull VAmPI as the quick-start target:

docker network create zapnet
docker run -d --name vampi --network zapnet erev0s/vampi:latest
docker run -d --name zap --network zapnet -p 8080:8080 -u zap zaproxy/zap-stable:latest

Importing the OpenAPI Spec and Exploring the API

How do you import an OpenAPI specification into ZAP? Install the “OpenAPI Support” add-on from the ZAP marketplace (Help → Check for Updates → Marketplace). Then use Import → Import an OpenAPI Definition, paste the spec URL (http://vampi:8000/swagger.json for VAmPI), and choose the target host. ZAP registers every documented endpoint in the Sites tree with example requests ready to attack.

Before scanning, seed real traffic. The Quick Start scan gives you a fast first pass, but the real work is manual exploration: proxy curl or Postman through ZAP (curl -x http://localhost:8080 http://vampi:8000/user/1) and click through the UI if the target has one. ZAP’s passive scanner analyzes every request you generate—no attack traffic, just observation—and builds the site tree the active scan will depend on. An API the scanner has never seen is an API it will never test.

Configuring Authentication: Session Handling and an Authenticated User

How do you configure OWASP ZAP to scan an API that requires authentication? This is the part most tutorials skip, and it’s the difference between scanning a wall and scanning the building.

Create a Context. Right-click the target in the Sites tree → Include in Context → New Context. Scope it tightly to the API host and paths.
Define an authentication strategy. In the Context’s Authentication panel, pick your method. For token-based APIs (the common case), use Manual Authentication or a JSON-based auth script: ZAP sends your login request (e.g., POST /user/login with credentials), captures the token from the response.
Add a Session Handling Rule. Under Session Properties → Session Handling, create a rule that detects the auth token in the login response (regex like "token"s*:s*"([^"]+)") and injects it as an Authorization: Bearer header on every subsequent request. This is the workhorse of authenticated API scanning.
Verify. Check the session is valid via the Users panel and run a quick manual request through ZAP as the configured user. If the Sites tree shows authenticated responses (user data, not 401s), you’re in.

For browser-flow APIs (OAuth redirects, cookie sessions), ZAP’s browser-based authentication records your login once and replays it. Modern ZAP versions handle this well—but token injection remains more deterministic for REST APIs in CI.

Running the Active Scan with API Policies

Right-click the context → Attack → Active Scan. Before you hit start, open the scan policy (Analyze → Scan Policy) and enable the API-relevant checks: SQL injection, remote OS command injection, path traversal, and—critically for APIs—the Unrestricted File Upload and Server-Side Include scanners. Disable heavyweight client-side checks (DOM XSS) that don’t apply to pure JSON endpoints; they burn scan time for nothing.

Watch the alerts tab fill. On VAmPI you can expect command injection findings, SQL injection on the username parameter, verbose error leakage, and unsupported methods exposed. Each alert carries a confidence rating (False Positive, Low, Medium, High) and evidence in the response—your triage anchors.

Fuzzing Endpoints with the ZAP Fuzzer

The active scan covers breadth; the built-in Fuzzer covers depth. Highlight a parameter in a request from the Sites tree, right-click → Fuzz, and choose your fuzz locations:

JSON body values: select the value inside the JSON payload—ZAP handles the syntax so your payloads don’t break the request.
Path parameters: fuzz /user/{id} with an ID enumeration list to probe for BOLA-style access control gaps.
Payload sources: file-based fuzzer payloads (grab a wordlist like SecLists), built-in string generators, or regex-derived values.

Keep it safe: fuzz only your own targets, respect rate limits (ZAP lets you set a delay between requests per thread), and never point payload lists at production. Fuzzing username with 50,000 payloads against a shared staging environment is how testers accidentally DoS their own infrastructure.

Mapping Results to the OWASP API Security Top 10

Which OWASP API Top 10 issues does ZAP detect dynamically? Here’s the honest map against the 2023 API Security Top 10:

API1: BOLA — ZAP flags signals (ID enumeration returning different users’ data) but can’t reliably confirm authorization logic. Scripted checks or manual fuzzing required.
API2: Broken Authentication — Detectable for missing auth on endpoints, weak token handling, and exposed auth flows. Notably, ZAP’s BChecks and scan rules cover header and session weaknesses.
API3: Broken Object Property Level Authorization — Mass assignment detection is largely outside ZAP’s dynamic reach; supplemental scripted tests needed.
API4: Unrestricted Resource Consumption — Partial coverage: ZAP can detect missing rate limiting via repeated requests, but quantifying throttling policy needs manual or load-tool work.
API5: Broken Function Level Authorization — Same class as BOLA; signals only.
API7/API8/API10 (SSRF, Security Misconfiguration, Unsafe Consumption) — Misconfiguration is ZAP’s strength: missing security headers, verbose errors, permissive CORS, exposed methods all get flagged reliably.
API6/API9 (Sensitive Data, Improper Inventory) — Error leakage and cleartext responses get flagged; inventory drift (shadow endpoints) is beyond any scanner fed a single spec.

The pattern: configuration and injection flaws—yes; authorization and business logic—mostly no. Plan your manual testing budget accordingly.

Automating with ZAP CLI, Docker, or the Python API

How can ZAP API scans be automated in CI/CD? The official packaging ships automation scripts purpose-built for this:

docker run --rm --network zapnet -v $(pwd):/zap/wrk/:rw zaproxy/zap-stable 
  zap-full-scan.py -t http://vampi:8000/swagger.json 
  -r report.html -I

zap-baseline.py runs passive checks only—fast, non-intrusive, ideal for pull requests. zap-full-scan.py runs active attacks—use it against staging on merge or nightly. For authenticated scans in automation, the cleanest path is the ZAP API: launch ZAP headless, configure the context and session rule via the REST API (/JSON/context/action/newContext, /JSON/reveal), then drive the scan from Python. GitHub Actions wrappers like zaproxy/action-full-scan reduce this to a YAML stanza. Exit codes are controllable (-I to not fail on warnings), letting you tune pipeline gates.

Triaging Alerts and Avoiding False Positives

DAST output is a lead list, not a verdict. Your workflow:

Filter by confidence first. High-confidence alerts with clear response evidence get verified manually; low-confidence noise goes to the back of the queue.
Reproduce by hand. Replay the exact request in curl or Postman. If the vulnerability doesn’t manifest outside ZAP, mark it accordingly.
Re-test after fixes. Re-run the same policy against the fixed build and diff the alerts—this is where automation in CI pays off, since re-testing becomes a push-button operation.

Beyond the Lab: Scaling DAST in Real Pipelines

The lab patterns scale, but production adds constraints. Scan windows matter: full active scans against staging can take hours on large API surfaces—schedule them off-peak, use baseline scans for fast feedback on every PR. Enforce staging-vs-prod policy hard: active scanning belongs on staging only; production gets passive monitoring at most. Combine ZAP with SAST (Semgrep, CodeQL) and, where available, spec-driven contract testing—OWASP’s own guidance treats API security as a defense-in-depth problem, and your pipeline should reflect that. Rate-aware scanning—throttling your own scanner to respect the target’s limits—keeps you from being your own outage.

Key Takeaways and Further Resources

The workflow: stand up an isolated vulnerable API, import its OpenAPI spec, configure a context with session handling and an auth strategy, run a scoped active scan, fuzz the interesting parameters, then map alerts against the OWASP API Security Top 10 with clear eyes about what DAST can and cannot prove. Automate the repeatable parts and re-test on every fix.

Frequently Asked Questions

Can OWASP ZAP scan authenticated APIs?

Yes. You configure a context, define an authentication strategy (browser-based or header/token via manual or scripted auth), and add a session handling rule that extracts the token and injects it into every request. Setup effort varies: static bearer tokens take minutes; OAuth flows with redirects take longer.

Which OWASP API Top 10 issues does ZAP detect?

Reliably: broken auth headers, injection flaws, error leakage, security misconfiguration, and some resource-consumption issues. BOLA, mass assignment, and business-logic flaws mostly need manual or scripted checks—ZAP gives you signals, not confirmations, for those categories.

Is it legal to scan any API with ZAP?

No. Only scan APIs you own or have written authorization to test. Keep a scope statement and lab environment for your own services, and treat authorization as the first step of every engagement.

Do I need an OpenAPI spec to use ZAP on an API?

It’s not required but highly recommended—the importer populates the site tree instantly. Without a spec, proxy manual traffic through ZAP or use the spider to seed discovery; you’ll cover less surface with more effort.

How do I run ZAP API scans in CI?

Use the official Docker images with zap-baseline.py or zap-full-scan.py pointed at the OpenAPI URL, or drive the scan programmatically via ZAP’s REST API from Python or GitHub Actions. Baseline scans for PRs, full authenticated scans for staging on merge.

Published by Hmmnm

Hands-on cybersecurity tutorials, CVE breakdowns, and guided learning paths — written and lab-tested by the Hmmnm team.

Learning Paths · About Hmmnm · Editorial policy

🛡️ Hmmnm also delivers this expertise as a service — security testing, assessment & training.