OWASP ZAP Tutorial: Scan A Web App In Kali Linux

✨ AI Summary

This tutorial covers OWASP ZAP, a free open-source web application security scanner, as part of a structured penetration testing workflow. The article explains ZAP's four scanning modes (passive, spider, AJAX spider, and active scanning), how to configure and deploy it, and how to interpret and act on its findings. ZAP serves as the automated baseline assessment tool that runs after reconnaissance to identify obvious vulnerabilities before manual testing begins.

Key insights

ZAP's four distinct scanning architecturesZAP operates as an intercepting proxy with four modes: passive scanning (analyzes traffic without sending additional requests, safe for production), spider (follows HTML links to discover URLs), AJAX spider (runs a headless browser to render JavaScript and find dynamically loaded content), and active scanning (sends deliberate attack payloads). Each mode serves a different purpose in the discovery and exploitation workflow, with the choice dependent on the target environment and authorization level.
AJAX Spider essential for modern applicationsTraditional HTML spiders miss most endpoints in JavaScript-heavy applications like React SPAs, finding only 3-4 URLs while AJAX spiders using headless browsers discover 40+ endpoints by rendering JavaScript and clicking navigation elements. The article demonstrates this with a concrete example where traditional spider missed /admin/settings and other JavaScript-routed endpoints that the AJAX spider found, making it critical for testing modern single-page applications.
Alert triage by risk and confidence combinationZAP assigns each finding a Risk level (High/Medium/Low/Informational) and Confidence level (High/Medium/Low). The combination determines investigation priority: High/High findings (strong evidence of serious vulnerability) get immediate verification, High/Low findings (suspected but uncertain) require manual testing, while Low-risk findings are typically configuration issues for remediation passes. This matrix prevents wasting manual testing time on false positives or low-impact findings.
SSL certificate configuration requirementZAP must have its root CA certificate imported into the browser and trusted for website identification to intercept and analyze HTTPS traffic. Without this configuration step, HTTPS requests fail with certificate errors and ZAP cannot inspect encrypted traffic. The process involves exporting ZAP's certificate and importing it into Firefox preferences under Privacy & Security.
Active scanning payload coverage and limitationsZAP's active scanner tests 40+ vulnerability classes including SQL injection (error, boolean, time-based), XSS (reflected/stored/DOM), command injection, path traversal, LDAP injection, and XML injection. However, the article explicitly notes ZAP finds zero CSRF vulnerabilities, misses some stored XSS contexts, and cannot identify IDOR or logic-layer vulnerabilities because it lacks understanding of business logic.
CLI and Docker integration for CI/CD pipelinesZAP provides three Docker images for pipeline automation: zap-baseline.py (passive scanning only, safe for CI/CD), zap-full-scan.py (active scanning for staging environments), and zap-api-scan.py (for OpenAPI/Swagger targets). These enable automated vulnerability scanning on every pull request touching authentication or API endpoints without requiring manual GUI interaction.
ZAP plus Nikto complementary coverageThe article demonstrates that ZAP and Nikto together provide superior coverage than either tool alone. Nikto excels at detecting server version disclosure, CGI vulnerabilities, and HTTP method abuse that ZAP misses, while ZAP finds SQL injection and XSS that Nikto misses. Running both tools adds only 5 minutes to the assessment but significantly improves baseline detection before manual testing.
Spider execution order and authorization strategyThe article emphasizes that passive scanning and spidering are safe on production systems without additional authorization, but active scanning—which sends attack payloads—requires explicit written permission and should never run against production. The recommended sequence on authorized staging systems is spider, passive scan, then active scan to build comprehensive coverage while managing risk.

Bottom line: OWASP ZAP functions as the essential automated scanning baseline in professional web application assessments, finding obvious injection flaws and misconfigurations in 20 minutes, though it must be combined with manual testing and tools like Nikto to address logic-layer vulnerabilities and achieve complete coverage. Proper configuration (SSL certificates, API key setup), scanner selection (AJAX spider for JavaScript applications), and alert triage (prioritizing High/High confidence findings) are

🗡️ KALI LINUX COURSE
FREE

Part of the 180-Day Kali Linux Mastery Course

Day 24 of 180 · 13.3% complete

⚠️ Authorised Targets Only. OWASP ZAP active scanning sends attack payloads — never run active scans against systems without explicit written authorisation. Use DVWA, HackTheBox, TryHackMe, or your own lab for all exercises. Passive scanning and spidering against your own applications in development is fine.

Fierce gave me the DNS map. Shodan gave me the service fingerprint. Now I’ve got a list of live web applications and I need to find what’s actually vulnerable in them. That’s where OWASP ZAP comes in — it’s the automated scanner I run before I start manual testing. Not because it finds everything (it doesn’t), but because it finds the obvious misconfigurations and baseline vulnerabilities in 20 minutes so I can spend my manual testing time on the interesting, logic-layer stuff that no scanner touches. Free, open source, and good enough to have replaced commercial scanners on plenty of engagements. Let me show you exactly how I use it.

🎯 What You’ll Master in Day 24

Configure OWASP ZAP as a browser proxy and understand its scanning architecture

Run spider, passive scan, and active scan against a practice target

Use the AJAX Spider for JavaScript-heavy single-page applications

Interpret ZAP’s alert severity and confidence ratings correctly

Generate professional scan reports and integrate ZAP into a CLI pipeline

⏱️ 40 min read · 3 exercises · Day 24 of 180

✅ Before You Start

Day 23: Fierce DNS Recon — DNS reconnaissance is complete. The live host list from Day 23 feeds into ZAP scanning today.
DVWA running locally at http://localhost/dvwa/ for the active scan lab. OWASP ZAP is pre-installed in Kali — launch with zaproxy from terminal.

📋 Day 24 — OWASP ZAP Tutorial

ZAP’s Architecture — The Four Scanning Modes
Installation and Proxy Setup in Kali 2026
Spider and AJAX Spider — Mapping the Attack Surface
Active Scan — Finding Real Vulnerabilities
Reading Alerts and Generating Reports
ZAP CLI and Pipeline Integration

After Day 23’s Fierce DNS recon surfaced the live web applications on my target scope, the next phase is systematic vulnerability scanning. ZAP is where I start — it’s the closest thing to ‘run it and see what lights up’ that I trust in a professional context. The Kali Linux Mastery Course builds the complete assessment workflow: recon → scanning → manual exploitation.

Key takeaways · updated Nov 2026

ZAP works as a proxy: browse the target through it, then spider, AJAX-spider and actively scan what it found.
The AJAX Spider is essential for JavaScript-heavy apps the classic spider can't crawl.
Active scans send real attack payloads, so only run them on targets you're authorised to test.
Run ZAP headless in CI pipelines to catch regressions automatically.

ZAP’s Architecture — The Four Scanning Modes

ZAP operates as an intercepting proxy sitting between your browser and the target. Every request and response passes through it. That’s the foundation for all four of its scanning modes.

Passive scanning runs continuously as you browse — ZAP analyses traffic without sending any additional requests to the target. Active scanning sends deliberate attack payloads. The spider crawls the application to discover URLs. The AJAX spider uses a headless browser to render JavaScript and discover dynamically loaded content that a traditional spider misses.

ZAP SCANNING MODES — QUICK REFERENCE

# Launch ZAP

zaproxy & # GUI mode (background)

zaproxy -daemon -port 8080 # Headless daemon mode

# Quick Start — automated scan (GUI)

Quick Start tab → URL to attack → Automated Scan → Attack

This runs: spider + passive scan + active scan in sequence

# Proxy setup — route browser through ZAP

Browser proxy: 127.0.0.1 port 8080

Or use ZAP’s built-in browser: Tools → Open Browser

# Four modes summary

1. Passive scan — analyses traffic, no extra requests, safe for prod

2. Spider — follows HTML links to map URLs

3. AJAX Spider — headless browser for JS-rendered content

4. Active scan — sends attack payloads — AUTHORISED ONLY

Installation and Proxy Setup in Kali 2026

ZAP is pre-installed in Kali Linux 2026. The main thing you need to configure is the SSL certificate — without it, ZAP can’t inspect HTTPS traffic and you’ll see certificate errors in your browser.

ZAP SETUP — PROXY AND SSL CERTIFICATE

# Verify ZAP is installed

which zaproxy # /usr/bin/zaproxy if installed

sudo apt install -y zaproxy # Install if missing

# Generate and export ZAP root CA certificate

ZAP → Options → Network → Server Certificates → Save Root CA Certificate

Save as: zap-root-ca.cer

# Import CA cert into Firefox (for HTTPS interception)

Firefox → Preferences → Privacy & Security → Certificates → Import

Select: zap-root-ca.cer → Trust: “Trust this CA to identify websites”

# Set browser proxy to ZAP

Firefox → Settings → Network → Manual proxy → 127.0.0.1:8080

# Or use ZAP’s built-in browser (no proxy config needed)

ZAP → Tools → Open Browser → Chromium

🧠 EXERCISE 1 — THINK LIKE A HACKER (15 MIN · NO TOOLS)

Design Your ZAP Scan Strategy Before Touching the Tool

⏱️ 15 minutes · No tools required

Before running any scan, the professional decision is: which mode do I use and in what order? Your answer changes the quality of results and the risk to the target. Work through this before you open ZAP.

SCENARIO: You have authorised access to test a web application.
The target has three environments:
– Production (live users, real data): api.target.com
– Staging (test data, same codebase): staging.target.com
– Dev (local Docker, no users): localhost:8080

QUESTION 1 — Mode selection by environment
Which ZAP modes are safe on PRODUCTION without risk of disruption?
Which modes should NEVER run on production?
What is the maximum safe action on a live production endpoint?

QUESTION 2 — Scan order
You’re testing staging.target.com. What order do you run the modes?
a) Active scan first → spider → passive
b) Spider → passive → active
c) AJAX spider → spider → passive → active
d) Passive only then manual testing
Explain why your chosen order is correct.

QUESTION 3 — AJAX Spider need
Target is a React SPA (single-page application). The traditional
spider finds 3 URLs. You know the app has 40+ routes.
What does this tell you about the spider results?
Which ZAP feature do you need and why?

QUESTION 4 — Alert triage
ZAP returns: 2 High (SQLi) at High confidence, 1 High (XSS) at Low
confidence, 14 Medium at Medium confidence, 40 Low at High confidence.
In what order do you manually verify these? What does Low confidence mean?
Are the 40 Low/High alerts worth investigating?

Document your scan strategy for a typical staging target.

✅ The confidence rating question is where most new ZAP users get tripped up. High Risk / Low Confidence means ZAP thinks a serious vulnerability exists but isn’t certain — these need manual verification. High Risk / High Confidence means ZAP has strong evidence — these get manual verification first, but they’re usually real. The order that wastes the least time: High/High first, High/Medium second, skip Low risk entirely on initial triage. Low alerts are almost always informational findings like missing headers that you address in remediation, not exploitable vulnerabilities.

📸 Write your scan strategy and share in #kali-labs.

Spider and AJAX Spider — Mapping the Attack Surface

The spider is your URL discovery phase — it builds the site map that active scanning then attacks. A spider that misses 60% of the application’s endpoints is useless. Traditional HTML spiders miss everything rendered by JavaScript. The AJAX spider runs a headless browser, clicks buttons, navigates routes, and catches dynamic content the standard spider never sees.

ZAP SPIDER AND AJAX SPIDER

# Traditional spider (HTML links only)

ZAP GUI: Sites tree → right-click target → Attack → Spider

# CLI equivalent

curl “http://localhost:8080/JSON/spider/action/scan/?url=http://target.com&apikey=mykey”

# AJAX Spider (for JS-heavy apps / React / Angular / Vue)

ZAP GUI: Spider tab → AJAX Spider → Target URL → Start Scan

# CLI equivalent

curl “http://localhost:8080/JSON/ajaxSpider/action/scan/?url=http://target.com&apikey=mykey”

# Check spider results

Sites tree (left panel) — all discovered URLs with method icons

Spider tab → Results tab — shows all crawled URLs and status codes

# Passive scan runs automatically during spidering

Alerts tab → shows findings from passive analysis of spidered pages

Common passive findings: missing X-Frame-Options, insecure cookies, info disclosure

securityelites.com

Traditional Spider vs AJAX Spider — Coverage Comparison
Traditional Spider — HTML Only
$ spider → found 3 URLs
/index.html
/login.html
/about.html
❌ Missed: /dashboard /api/users /profile/edit /admin/settings
(all loaded via JavaScript router)
AJAX Spider — Headless Browser
$ ajaxSpider → found 47 URLs
/index.html · /login · /about
/dashboard · /profile/edit
/api/users · /api/posts
/admin/settings ← HIGH VALUE
✅ Rendered JS, clicked buttons, followed routes

📸 Spider coverage comparison on a React SPA. The traditional HTML spider finds 3 static pages. The AJAX spider finds 47 endpoints by running a headless browser, navigating routes, and clicking interactive elements. The /admin/settings endpoint — highest-value target — only appears with AJAX spider. For any modern JavaScript-heavy application, skipping the AJAX spider means missing most of the attack surface.

Active Scan — Finding Real Vulnerabilities

Active scanning is where ZAP tests each discovered endpoint with attack payloads. It’s the most impactful part of automated scanning and the part that requires authorisation. Running it against DVWA or any practice target shows you exactly what ZAP’s scanner is capable of finding.

ZAP ACTIVE SCAN — CONFIGURATION AND EXECUTION

# Active scan from GUI

Sites tree → right-click target → Attack → Active Scan

Scan Policy: Default Policy (all categories enabled)

Technology: Select target tech stack for targeted scanning

# Active scan from CLI (daemon mode)

curl “http://localhost:8080/JSON/ascan/action/scan/?url=http://dvwa.local&recurse=true&apikey=mykey”

# Monitor scan progress

curl “http://localhost:8080/JSON/ascan/view/status/?scanId=0&apikey=mykey”

# Returns: {“status”:”85″} = 85% complete

# Scan policy — focus on specific vulnerability classes

Analyse → Scan Policy Manager → Add Policy → configure

SQLi only: disable all except “SQL Injection” category

XSS only: disable all except “Cross Site Scripting” category

# What active scan tests

SQL Injection (error, boolean, time-based) · XSS reflected/stored

Command injection · Path traversal · Remote file inclusion

LDAP injection · XML injection · SSI injection · Buffer overflow

Reading Alerts and Generating Reports

ZAP’s alerts panel is where the value sits. Every finding has a Risk (High/Medium/Low/Informational) and Confidence (High/Medium/Low/False Positive). The combination tells me how to triage: I manually verify High/High first, then High/Medium. Low confidence findings need manual testing to confirm — the scanner isn’t sure. False Positive markers let you suppress known safe findings from reports.

ZAP ALERT TRIAGE AND REPORT GENERATION

# Alert risk × confidence matrix — triage priority

High/High → Verify immediately, almost certainly real

High/Medium → Verify next, likely real

High/Low → Manual test required, may be false positive

Medium/High → Schedule for manual verification

Low/* → Address in remediation pass, not manual exploit

# Generate HTML report

ZAP → Report → Generate Report → HTML format

Include: All risk levels → Output file: zap-report.html

# CLI report generation

curl “http://localhost:8080/OTHER/core/other/htmlreport/?apikey=mykey” -o report.html

curl “http://localhost:8080/OTHER/core/other/jsonreport/?apikey=mykey” -o report.json

# Export alerts to CSV for spreadsheet analysis

curl “http://localhost:8080/OTHER/core/other/alertsFile/?apikey=mykey” -o alerts.csv

securityelites.com

ZAP Alert Panel — Risk × Confidence Triage
Alert
Risk
Confidence
Action
SQL Injection
High
High
Verify NOW — almost certainly real
XSS Reflected
High
Low
Manual test required — may FP
Missing CSP Header
Medium
High
Add to report — config fix
X-Frame-Options Missing
Low
High
Remediation pass — no exploit

📸 ZAP alert triage by risk/confidence combination. SQL Injection at High/High gets verified immediately — ZAP has strong evidence. XSS at High/Low needs manual verification — the scanner suspects it but isn’t sure, and false positives at High risk are common for reflected XSS. Medium/High header findings are real but not exploitable vulnerabilities — they go in the report as hardening recommendations. Low/High findings are config issues to address in a remediation pass rather than pentest findings.

ZAP CLI and Pipeline Integration

ZAP’s CLI mode is what makes it genuinely useful in 2026 — it integrates into CI/CD pipelines to catch vulnerabilities before code reaches staging. The Docker image makes this clean and reproducible. For security engineers, this means running ZAP on every pull request that touches authentication or API endpoints.

ZAP CLI AND DOCKER PIPELINE

# ZAP baseline scan (passive only — safe for CI/CD)

docker run -t ghcr.io/zaproxy/zaproxy zap-baseline.py \

-t http://staging.target.com \

-r zap-baseline-report.html

# ZAP full scan (active — staging only)

docker run -t ghcr.io/zaproxy/zaproxy zap-full-scan.py \

-t http://staging.target.com \

-r zap-full-report.html \

-I # Continue even if High alerts found

# ZAP API scan (for OpenAPI/Swagger targets)

docker run -t ghcr.io/zaproxy/zaproxy zap-api-scan.py \

-t http://api.target.com/openapi.json \

-f openapi \

-r zap-api-report.html

# Daemon mode with API key

zaproxy -daemon -port 8080 -config api.key=changeme &

sleep 10 # Wait for startup

curl “http://localhost:8080/JSON/core/view/version/?apikey=changeme”

⚡ EXERCISE 2 — KALI TERMINAL (30 MIN · DVWA REQUIRED)

Run a Full ZAP Scan Against DVWA — Spider, Passive, Active

⏱️ 30 minutes · Kali Linux + DVWA running at localhost

This is the hands-on core of Day 24. Run ZAP’s complete scan workflow against DVWA and compare what the automated scanner finds vs what you found manually in earlier labs. The gap teaches you both what ZAP is good at and where manual testing is irreplaceable.

PREREQUISITE: DVWA running at http://localhost/dvwa/ with security set to Low.
ZAP launched (zaproxy &) with browser proxy configured to 127.0.0.1:8080.

Step 1: Log into DVWA through ZAP proxy
Browse to http://localhost/dvwa/ via your ZAP-proxied browser.
Log in as admin/password. This authenticates the session ZAP uses.
Check Sites tree — DVWA URLs should appear.

Step 2: Run traditional spider
Sites tree → right-click http://localhost → Attack → Spider
Max Depth: 5, Max Children: 10
Watch the Sites tree populate with DVWA module URLs.
Count: how many URLs discovered?

Step 3: Run AJAX Spider
Spider tab → AJAX Spider → Target: http://localhost/dvwa/
Let it run for 2 minutes.
Count: how many NEW URLs appeared vs traditional spider?

Step 4: Review passive scan alerts
Alerts tab → sort by Risk
What Medium/Low alerts appeared from passive scanning?
List the missing security headers ZAP detected.

Step 5: Run active scan
Sites tree → right-click localhost → Attack → Active Scan
Scan Policy: Default Policy
Wait for scan to reach ~50% then check Alerts tab.
What High-risk alerts has ZAP found so far?
Compare to what you found manually: SQLi, XSS, CMDi?

Step 6: Generate report
Report → Generate Report → HTML
Save as dvwa-zap-report.html
Open in browser — how many total alerts by severity?
How many did ZAP miss that you found manually?

✅ The comparison in Step 6 is the most instructive moment. ZAP typically finds all the SQL injections and many of the XSS findings in DVWA, but misses CSRF entirely (it can’t understand application business logic), misses stored XSS in some contexts, and finds zero IDOR vulnerabilities. That’s the boundary of automated scanning: it excels at injection flaws with clear signal, fails completely at logic-layer vulnerabilities. Manual testing fills the gap. Your ZAP report from this exercise is also good practice for reading automated scan output the way a client expects to receive it.

📸 Screenshot your ZAP Alerts panel showing High findings. Share in #kali-labs.

📋 ZAP Command Reference — Day 24

zaproxy & # Launch ZAP GUI in background

zaproxy -daemon -port 8080 -config api.key=KEY # Headless daemon

curl “http://localhost:8080/JSON/spider/action/scan/?url=URL&apikey=KEY” # Spider API

curl “http://localhost:8080/JSON/ascan/action/scan/?url=URL&apikey=KEY” # Active scan API

docker run ghcr.io/zaproxy/zaproxy zap-baseline.py -t URL -r report.html # Docker baseline

docker run ghcr.io/zaproxy/zaproxy zap-full-scan.py -t URL -r report.html # Docker full scan

⚡ EXERCISE 3 — KALI TERMINAL (20 MIN)

ZAP + Nikto Pipeline — Two Scanners, One Assessment

⏱️ 20 minutes · Kali Linux + DVWA

No single scanner covers everything. Running ZAP and Nikto together takes 5 extra minutes and catches what each misses. Nikto is fast, has great server misconfiguration coverage, and produces output you can grep. ZAP has superior injection detection. Together they’re the standard automated scanning baseline before manual testing begins.

TARGET: http://localhost/dvwa/ (DVWA at Low security)

Step 1: Nikto scan (run while ZAP active scan is running)
nikto -h http://localhost -port 80 -output nikto-dvwa.txt -Format txt
What does Nikto find that ZAP’s passive scan missed?
Any server headers or configuration issues?

Step 2: ZAP active scan (run simultaneously)
zaproxy -daemon -port 8080 -config api.key=mykey &
sleep 10
curl “http://localhost:8080/JSON/ascan/action/scan/?url=http://localhost/dvwa/&apikey=mykey”

Step 3: Compare findings
Nikto findings: list all Medium+ severity
ZAP findings: list all High + Medium
Findings in Nikto only (not in ZAP)?
Findings in ZAP only (not in Nikto)?
Total unique findings = ZAP_unique + Nikto_unique + overlap

Step 4: Combine into unified finding list
Create a text file: combined-scan-findings.txt
List: Finding | Tool | Severity | URL
How many total unique vulnerabilities across both tools?

Step 5: Generate ZAP report
curl “http://localhost:8080/OTHER/core/other/htmlreport/?apikey=mykey” \
-o zap-report.html
Open and compare against your Nikto output.

✅ The coverage comparison (Step 3) reliably shows Nikto finding server version disclosure, CGI vulnerabilities, and HTTP method abuse that ZAP misses, while ZAP finds SQLi and XSS that Nikto misses. Neither tool alone provides complete coverage — running both takes 5 extra minutes and significantly improves your baseline before manual testing begins. Your combined finding list is the kind of output that goes into the automated scanning section of a professional pentest report.

📸 Screenshot your combined findings list with source tool column. Share in #kali-labs. Tag #Day24

🏆 Day 24 Complete — OWASP ZAP Tutorial

Spider vs AJAX spider, passive vs active scan, alert triage by risk/confidence, report generation, CLI mode, and the ZAP + Nikto combined pipeline. ZAP is now in your standard pre-manual assessment workflow. Day 25 moves to BeEF-XSS — the Browser Exploitation Framework that turns an XSS vulnerability into a full remote browser control channel.

🧠 Quick Check

You’re assessing a React single-page application. ZAP’s traditional spider finds 4 URLs. You know the application has over 50 routes. What should you do, and why does this matter for the active scan that follows?

❓ Frequently Asked Questions — OWASP ZAP 2026

What is OWASP ZAP used for?

ZAP is a free open-source web application security scanner used for automated and manual testing. Key capabilities: intercepting proxy, spider and AJAX spider for URL discovery, passive scan (no attack traffic — safe for prod), active scan (attack payloads — authorised targets only), and API scanning with OpenAPI import support.

Is ZAP better than Burp Suite?

They serve different primary roles. ZAP excels at automated scanning, CI/CD pipeline integration, AJAX spider, and budget-constrained environments (fully free). Burp Pro excels at manual web app pentesting with superior Repeater and Intruder. Professional pentesters use both — ZAP for automated baseline, Burp for manual deep testing.

What does the active scanner test for?

40+ vulnerability classes including: SQL injection (error/boolean/time-based), XSS reflected/stored/DOM, command injection, path traversal, remote file inclusion, LDAP injection, XML injection, and security header misconfigurations. Configurable via scan policies to enable/disable categories.

How do I configure ZAP for HTTPS scanning?

Export ZAP’s root CA: Options > Network > Server Certificates > Save Root CA. Import into Firefox: Preferences > Privacy & Security > Certificates > Import > trust for websites. ZAP then decrypts and analyses HTTPS traffic transparently.

Can ZAP scan APIs?

Yes. Import OpenAPI/Swagger spec via Import > Import OpenAPI from URL/file to auto-populate all endpoints. GraphQL add-on available for schema introspection and scanning. Without specs, use ZAP as proxy during Postman/curl exploration to capture and then scan all endpoints.

What is passive scan vs active scan?

Passive scan analyses traffic passing through ZAP without sending additional requests — safe for production. Active scan sends attack payloads to test for exploitable vulnerabilities — significant traffic, authorised targets only, never production. Run spider + passive on prod; save active scan for test/staging with explicit permission.

← Previous

Day 23: Fierce — DNS Recon & Zone Transfers

Day 25: BeEF-XSS — Browser Exploitation Framework

📚 Further Reading

Day 23 — Fierce DNS Recon — The DNS recon phase that precedes ZAP scanning. Fierce surfaces the live web applications that ZAP then scans — the two tools connect directly in a professional assessment workflow.
Day 25 — BeEF-XSS Framework — Day 25 takes the XSS findings ZAP surfaces and escalates them using the Browser Exploitation Framework — turning a scanner finding into a live browser control channel.
Web Application Security Hub — The vulnerability classes ZAP scans for — SQLi, XSS, command injection — each covered in depth with manual exploitation methodology and bug bounty reporting guides.
OWASP ZAP Official Documentation — The authoritative ZAP reference covering all scan modes, API documentation, scan policy configuration, add-ons, and CI/CD integration guides. Essential reading for building ZAP into a professional assessment workflow.
ZAP GitHub Releases — Docker Images — ZAP’s official Docker images (zap-baseline.py, zap-full-scan.py, zap-api-scan.py) for CI/CD pipeline integration. The source for the docker run commands used in today’s CLI section.

Mr Elite

Owner, SecurityElites.com

The engagement that changed how I use ZAP was on a microservices platform with 23 API endpoints. I ran ZAP’s traditional spider, got 6 URLs, ran the active scan, found nothing interesting. Three hours of manual testing later, I’d found 4 Medium findings. Then I imported the OpenAPI spec into ZAP and ran it again. In 20 minutes it found 2 High findings — authentication bypass and IDOR — that I’d completely missed manually because I hadn’t tested those endpoints in the right parameter order. ZAP didn’t replace my manual testing. But it found two things I didn’t. Now importing the spec is the second thing I do on every API engagement, right after reading the documentation.

OWASP ZAP Tutorial 2026 — Automated Web Scanning, Spider & Active Attack | Kali Linux Tools Day24