OWASP ZAP with Dradis
Web application security tool
The OWASP Zed Attack Proxy (ZAP) is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. With the Dradis ZAP integration, ingest the results of ZAP tests, combine the findings with output from other security tools, update details for remediation, and quickly generate a custom web application vulnerability report.
The OWASP ZAP® name, if trademarked, is the intellectual property of the vendor. Uses of the OWASP ZAP® name in this page are for identification purposes only and do not imply an endorsement by the trademark owner. Dradis is not endorsed or owned by, or affiliated with, the OWASP ZAP® vendor.
Jeffrey von Rotz
Cyber Security Engineer at Rotz SecurityAvailable for
Vendor
Support Documentation
OWASP ZAP (Zed Attack Proxy) is a free, open-source web application security scanner maintained by the OWASP Foundation. It provides automated scanners as well as tools for manual security testing, making it a staple in web application penetration testing. This guide walks you through importing ZAP XML scan results into Dradis so you can consolidate findings, map evidence to affected hosts, and build professional reports without re-typing every alert.
After a ZAP scan completes, you're left with an XML report containing alerts grouped by site. Each alert may have dozens of affected URLs (instances). Manually transferring these into a report is tedious and error-prone. The Dradis ZAP plugin automates this:
<site> element in the ZAP report, so multi-site scans stay organized.This structure lets your team review findings by host, by severity, or by vulnerability ty†nesspe — all from a single import.
Before you begin, make sure you have:
OWASPZAPReport XML output)Note: Dradis imports the ZAP XML report format. If you exported your ZAP results as HTML or JSON, re-export from ZAP using Report > Generate Report and select the XML format.
Log in to Dradis and navigate to your project. Click Upload in the top navigation bar to open the Upload Manager page.
The Upload Manager shows a dropdown for selecting the import plugin and a file picker for your scan output.
Click the plugin dropdown and select ZAP. This tells Dradis to parse the uploaded file using the OWASP ZAP importer, which expects the standard OWASPZAPReport XML schema.
Click Choose File and select your ZAP XML report. The file should be the standard XML export — the one that starts with <OWASPZAPReport> at the root element.
Click Upload to start the import. Dradis parses the XML, creates Issues from each <alertitem>, and creates Evidence entries from each <instance> within those alerts. A progress log shows the import activity.
The import log shows each alert being processed with its plugin ID, and evidence entries being created for each affected URL. In our sample, 10 alerts across 2 sites produced 10 Issues and 20 Evidence entries.
Navigate to the Issues tab to see all imported ZAP alerts. Each issue shows its title (the ZAP alert name), risk level, and the number of affected hosts.
ZAP alerts span the full severity spectrum. In a typical scan, you'll see High-risk findings like Cross Site Scripting and SQL Injection alongside Medium findings like missing X-Frame-Options headers and Low/Informational items like missing HSTS headers or loosely scoped cookies. This makes Dradis an effective triage tool — you can sort by severity and focus on what matters first.
Click any issue to see its full content. The issue detail view shows all the fields imported from ZAP, formatted using Dradis field mapping.
Each issue contains the alert title, risk description, confidence level, detailed description, recommended solution, other information, and references including CWE and WASC identifiers. This gives you everything needed for the finding description section of your report.
The sidebar shows nodes created from the ZAP report. Each <site> element in the XML becomes a node labeled with the hostname. Expand the Scanner output tree to see all target hosts.
In our example, the two sites scanned (www.acmecorp.com and api.acmecorp.com) each appear as separate nodes. This multi-site organization is particularly useful when ZAP scans cover both a web application and its API backend.
Click a host node to see all evidence associated with that target. The Evidence tab lists every instance (affected URL, parameter, and attack payload) linked to that host.
Evidence entries show which specific URLs triggered each alert, making it easy to provide proof-of-concept details in your report. The host-centric view lets you answer the question: "What vulnerabilities affect this specific server?"
Click an individual evidence entry to see the full instance data. This includes the URI where the vulnerability was found, the affected parameter, and the attack payload that triggered the alert.
The evidence detail view maps directly to ZAP's <instance> elements. For active scan findings like XSS or SQL Injection, you'll see the exact attack payload used. For passive findings like missing headers, the evidence shows which URLs are affected.
The ZAP plugin maps XML elements to Dradis fields. Here's the complete mapping:
| Dradis Field | ZAP XML Source | Dradis Template Placeholder |
|---|---|---|
| Title | <alert> |
{{ zap[issue.alert] }} |
| Risk | <riskdesc> |
{{ zap[issue.riskdesc] }} |
| Confidence | <confidence> |
{{ zap[issue.confidence] }} |
| Description | <desc> |
{{ zap[issue.desc] }} |
| Solution | <solution> |
{{ zap[issue.solution] }} |
| OtherInfo | <otherinfo> |
{{ zap[issue.otherinfo] }} |
| References | <reference>, <cweid>, <wascid> |
{{ zap[issue.reference] }}, {{ zap[issue.cweid] }}, {{ zap[issue.wascid] }} |
Additional source fields available for custom mappings: issue.pluginid, issue.riskcode, issue.count.
| Dradis Field | ZAP XML Source | Dradis Template Placeholder |
|---|---|---|
| URI | <uri> in <instance> |
{{ zap[evidence.uri] }} |
| Param | <param> in <instance> |
{{ zap[evidence.param] }} |
| Attack | <attack> in <instance> |
{{ zap[evidence.attack] }} |
ZAP's XML report has a specific hierarchy that maps cleanly to Dradis:
OWASPZAPReport
└── site (hostname:port) → Dradis Node
└── alerts
└── alertitem → Dradis Issue
└── instances
└── instance → Dradis Evidence (linked to Issue + Node)
Key points about how this mapping works:
One node per site: If your ZAP scan targets www.example.com and api.example.com, you'll get two nodes. The node label comes from the host attribute of the <site> element.
One issue per alert: ZAP deduplicates findings by plugin ID. Each <alertitem> becomes exactly one Issue in Dradis, regardless of how many instances (affected URLs) it has.
Evidence preserves instance detail: Each <instance> inside an alert becomes a separate Evidence entry. This means a single XSS finding affecting 15 URLs creates 1 Issue and 15 Evidence entries, all linked to the same host node.
Risk codes map to severity: ZAP uses numeric risk codes (0=Informational, 1=Low, 2=Medium, 3=High) and the riskdesc field provides the human-readable version like "High (Medium)" where the parenthetical indicates confidence.
ZAP can generate two types of XML reports:
Both formats import correctly into Dradis. However, with merged reports, you may see the same alert (e.g., "X-Frame-Options Header Not Set") appear as evidence under multiple host nodes. This is expected and reflects ZAP's finding that the issue affects multiple targets.
ZAP active scans can produce hundreds of instances for common findings like missing security headers. When importing large reports:
ZAP excels at web application testing but doesn't cover infrastructure vulnerabilities. A common workflow:
Dradis automatically groups evidence by host. If ZAP found XSS on www.acmecorp.com and Nessus found an outdated TLS configuration on the same host, both findings appear under the same node — giving you a complete picture for that target.
Each ZAP alert has a pluginid that uniquely identifies the scanner rule that generated it. The plugin ID imports into Dradis as part of the issue's identifier. This is useful for:
cweid and wascid fields import into the References section, providing direct links to vulnerability databases.ZAP uses scan policies to determine which test rules run during active scanning. Different policies produce different alert types in the XML report:
The passive scanner results (missing headers, cookie flags, information disclosure) are always included regardless of active scan policy. These typically make up the majority of Low and Informational findings in your Dradis project.
For teams running ZAP in CI/CD pipelines or as part of automated testing, you can export results and import into Dradis programmatically:
core/xmlreport API endpointThis lets you build a fully automated pipeline where every build triggers a security scan and the results flow directly into your Dradis project for review. The ZAP plugin in Dradis handles incremental imports gracefully — existing issues are updated with new evidence rather than duplicated.
ZAP assigns both a risk level (severity) and a confidence rating to each finding. A "High (Low)" finding means high severity but low confidence — likely a false positive. Use this in Dradis to prioritize your manual verification:
In Dradis Pro, you can create custom report templates that conditionally include findings based on confidence level, using the {{ zap[issue.confidence] }} placeholder.
ZAP supports context-based scanning where you define authentication, session management, and user roles for the target application. When you scan an authenticated application, the resulting alerts may include findings in protected areas that anonymous scanning would miss. These findings import into Dradis just like any other alert, but the evidence URIs will reflect the authenticated paths (e.g., /admin/settings, /user/profile/edit).
If you run both authenticated and unauthenticated scans, import both reports into the same Dradis project. Dradis deduplicates issues by plugin ID, so common findings are consolidated while authenticated-only findings appear as additional evidence entries on the existing issues.
This error means Dradis couldn't find the expected /OWASPZAPReport/site XPath in your file. Common causes:
.session) rather than an exported report<OWASPZAPReport>If issues import but no evidence appears, your ZAP report may not contain <instances> elements. This happens with:
Ensure you're using ZAP 2.4+ and exporting the standard XML report from the GUI or the xmlreport API endpoint.
ZAP XML encodes HTML content using XML entities (<p> instead of <p>). Dradis handles this automatically during import, rendering the descriptions as formatted text. If you see raw HTML entities in your issues, check that you're using a current version of the Dradis ZAP plugin.
If your ZAP report scanned multiple sites but only some appear as nodes, verify the XML structure. Each <site> element must have a valid host attribute. Sites without a host attribute are skipped during import.
If you import the same ZAP report twice, you may see duplicate evidence entries. Dradis uses the ZAP plugin ID to identify existing issues and avoids creating duplicate issues, but evidence entries from the second import are added alongside the originals. To avoid this, delete existing findings from the previous import before re-importing, or create a new project for the fresh import. In Dradis Pro, the Merge feature gives you more granular control over how repeated imports are handled.
After importing your ZAP results:
Your email is kept private. We don't do the spam thing.