Wfuzz Integration with DefectDojo

Wfuzz Integration with DefectDojo

Wfuzz is an open source web application fuzzer written in Python, created by Xavier Mendez and published on GitHub under the GPL-2.0 license. Security testers use it to discover resources and behavior a web application doesn't advertise: it substitutes values from a dictionary or other source into a request template, sends the requests, and reports the responses that match the filters you set, such as status code, size, or word count. Wfuzz can write its results in several formats through its printers, including JSON, which DefectDojo imports.

Wfuzz Integration with DefectDojo

We use Wfuzz to find what shouldn't be reachable: admin consoles, status pages, backup files, and forgotten routes on our web applications. The problem with fuzzing output is that it is a list of hits with no follow-up. Importing Wfuzz results into DefectDojo turns each exposed URL into a Finding on the right Asset, with the endpoint recorded, an owner assigned, and an SLA running. When the next run shows the URL is gone, reimport closes it, and we have a record of when it was exposed and when it was fixed.

Why Wfuzz Matters

Crawlers only find what is linked. Many real exposures sit at paths nobody links to: debug pages, server status handlers, old API versions, and leftover files from deployments.

• Wfuzz discovers unlinked resources by testing candidate paths and parameters directly.
• Its filters let testers keep only meaningful responses, such as hiding 404s or showing only specific status codes.
• It is scriptable and fits into scheduled checks against staging or pre-production.
• It is free and open source, and common in penetration testing toolkits.
• Its findings describe exposure (CWE-200), which is often the first step toward a more serious issue and deserves follow-up.

Advantages of This Integration

What we gained by sending Wfuzz results through DefectDojo:

• Each exposed URL becomes a tracked Finding. The parser creates one Finding per unique URL and status code, with the URL's host, port, scheme, and path as an endpoint.
• Repeats collapsed. If the same URL and status code appear more than once in a file, they merge into one Finding with an occurrence count.
• Closure on reimport. Reimporting a new run into the same Test mitigates URLs that are no longer found and reactivates any that come back.
• Ownership and SLAs. Exposed resources get an owner, a deadline, notes, and optional Jira tickets, like any other finding.
• Context next to other DAST results. Wfuzz Findings sit on the same Asset as ZAP, Burp, or other scanner results for the same application.

How This Integration Works

DefectDojo imports Wfuzz results with the WFuzz JSON report scan type. The parser reads Wfuzz's JSON printer output, a JSON array with one object per result containing the URL, status code, and request.

1. Write Wfuzz results as JSON. Add the file output option with the json printer to the Wfuzz command you already run:

wfuzz -f wfuzz-report.json,json [your existing options and target]

Every result in the file becomes a Finding, so apply Wfuzz's filters (for example --hc to hide status codes or --sc to show only certain ones) in the run itself. Only test applications you own or are authorized to test.

2. Import the file. In the UI, open the Engagement, choose Import Scan Results, select WFuzz JSON report, and upload the file. With the API (Community Edition and DefectDojo Pro):

curl "https://YOUR_INSTANCE/api/v2/import-scan/" \
  -H "Authorization: Token $DD_API_TOKEN" \
  -F "scan_type=WFuzz JSON report" \
  -F "file=@wfuzz-report.json" \
  -F "product_name=marketing-site" \
  -F "engagement_name=Content Discovery" \
  -F "auto_create_context=true"

DefectDojo Pro users can use Universal Importer:

universal-importer import \
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" \
  --scan-type "WFuzz JSON report" \
  --report-path "./wfuzz-report.json" \
  --product-name "marketing-site" \
  --engagement-name "Content Discovery" \
  --auto-create-context

3. Reimport repeat runs. If you run the same discovery job on a schedule, reimport into the same Test with /api/v2/reimport-scan/ so URLs that were locked down are closed.

Data Granularity: What Gets Imported

Other fields in the Wfuzz output, such as response size, lines, words, and redirect location, are not imported. The title keeps the full URL as Wfuzz reported it, including any query string, while the endpoint records only the scheme, host, port, and path. Two results that differ only in their query string therefore become separate Findings that share one endpoint.

Use Cases

For scheduled exposure checks: A team runs a fixed Wfuzz discovery job against staging after each release and reimports the result. A newly reachable status page or admin route shows up as a High Finding because it returned 200, and it closes once access is restricted.

During a penetration test: A tester's Wfuzz results go into the pentest Engagement next to their manual findings, so every exposed resource has an owner after the report is delivered.

For legacy application cleanup: A platform team imports discovery results for older applications to inventory forgotten files and routes, then assigns each one for removal and tracks progress with metrics.

Alongside crawler-based DAST: Wfuzz Findings complement ZAP or Burp results on the same Asset by covering paths those tools never saw linked.

Operational Tips

• Treat severity as a hint, not a risk rating. It is based only on the HTTP status code, so a 200 on a harmless page is High and a 500 from a broken handler is Low. Adjust severity during triage.
• Filter in Wfuzz, not afterward. Unfiltered output can contain thousands of responses, and each unique URL and status code becomes a Finding.
• Expect a 403 to arrive as Medium. A forbidden response confirms the path exists, which may or may not matter for your application.
• Keep the job definition stable between runs. A different filter or dictionary changes which URLs appear, and reimport will mitigate anything missing.
• Because the title contains the full URL, the same path on different hosts is a separate Finding. Use one Asset per application to keep results grouped.
• Mark intentional public endpoints as false positives or accepted risk once, so repeat runs don't reopen them.