Dalfox Integration with DefectDojo

Dalfox Integration with DefectDojo

Dalfox is an open source cross-site scripting (XSS) scanner created by hahwul. It analyzes a target's parameters, sends injection payloads to the ones that look injectable, and reports what came back, distinguishing results it verified (the payload executed) from results where the payload was only reflected unencoded. Dalfox 2.x is written in Go and its successor, Dalfox 3, is a Rust rewrite. Results can be written as JSON, which DefectDojo imports.

Dalfox Integration with DefectDojo

We run Dalfox against staging builds of our web applications because it is fast and focused, and we import its JSON into DefectDojo because its raw output is noisy. A single injectable parameter can show up dozens of times in a Dalfox report, once per payload that worked. In DefectDojo, those attempts collapse into one Finding per parameter and endpoint, with the verified or reflected status preserved in the severity, so the team works on the actual injectable parameter instead of a wall of near-identical results.

Why Dalfox Matters

XSS remains one of the most common web application flaws, and broad DAST tools don't always exercise every parameter deeply.

• It concentrates on one vulnerability class and tests parameters with many payload variations.
• It separates verified results from reflected ones, which is the difference between a demonstrated issue and one that still needs a person to confirm exploitability in context.
• It records the injection point, the HTTP method, the evidence it saw, and a proof-of-concept URL.
• It is a command-line tool that is easy to run in a pipeline against a test environment.
• Its output is one entry per attempt, so without post-processing a single bug can look like forty.

Advantages of This Integration

What running Dalfox through DefectDojo adds:

• One Finding per injectable parameter. Every result is imported, then deduplication folds them together on the vulnerability ID, the parameter, and the endpoint. Extra payload attempts are recorded as duplicates rather than separate work items.
• Stable endpoints. The proof-of-concept URL becomes the endpoint with its query string dropped. The query holds the payload, which differs on every attempt, so keeping it would create a new endpoint per payload.
• Verified and reflected kept apart. The result type is part of the vulnerability ID from the tool, so a verified result never merges into a reflected one for the same parameter.
• Severity that reflects evidence. Dalfox's own severity is used directly: High for verified, Medium for reflected, Low for grep pattern matches.
• Payload and evidence on record. The payload, evidence, and proof of concept are stored on the Finding, which helps developers reproduce the issue and retesters confirm the fix.
• Standard workflow. XSS findings get CWE-79, follow SLAs by severity, and can be assigned, pushed to Jira, or marked false positive after review.

How This Integration Works

DefectDojo imports Dalfox output with the Dalfox Scan scan type.

1. Produce a JSON report. With Dalfox 2.x, scan a target URL and write JSON:

dalfox url https://staging.example.com/search --format json -o dalfox.json

The parser was written against the JSON layout of Dalfox 2.x, which is kept on the project's v2 branch. Each result carries fields such as type, param, inject_type, payload, evidence, data (the proof-of-concept URL), cwe, and severity. Dalfox 3 changed the command-line interface (it is organized around a dalfox scan subcommand), so if you use Dalfox 3, confirm its JSON contains these fields before wiring it into a pipeline.

Dalfox 2.x ends its JSON array with an empty object. The parser skips it.

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select Dalfox Scan, and upload the file. To automate it, use the import API, available in Community Edition and DefectDojo Pro:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" 
  -H "Authorization: Token $DD_API_TOKEN" 
  -F "scan_type=Dalfox Scan" 
  -F "file=@dalfox.json" 
  -F "product_name=storefront" 
  -F "engagement_name=Staging DAST" 
  -F "auto_create_context=true"

DefectDojo Pro users can run the same import with Universal Importer:

universal-importer import 
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" 
  --scan-type "Dalfox Scan" 
  --report-path "./dalfox.json" 
  --product-name "storefront" 
  --engagement-name "Staging DAST" 
  --auto-create-context

3. Reimport after each deployment. Send later reports to /api/v2/reimport-scan/ for the same Test, so fixed parameters are mitigated and new injectable ones are added.

Data Granularity: What Gets Imported

Use Cases

DAST stage in CI/CD: After each deployment to staging, a pipeline runs Dalfox against the application's main entry points and reimports the results. A new verified XSS appears as a High finding on the Asset, and a gate can check for it through the DefectDojo API before promotion.

Supplementing a broad DAST scanner: A team uses a general DAST tool for coverage and Dalfox for deep XSS testing of search and form parameters. Both import into the same Asset, so the security lead sees one list of web findings rather than two reports.

Bug bounty and pentest preparation: Before opening an application to external testers, a team runs Dalfox and clears verified findings first. The DefectDojo history shows what was fixed before the program started.

Verifying fixes: After a developer adds output encoding, a reimport mitigates the finding if Dalfox no longer reports the parameter, which gives a retest record without a manual note.

Operational Tips

• Only scan applications you own or are authorized to test, ideally in staging. Dalfox sends live injection payloads.
• Expect a high duplicate count on first import. That is deduplication folding payload attempts together, not a problem with the import.
• Treat Medium (reflected) findings as leads. They need a person to confirm exploitability in context before they are prioritized like verified ones.
• Keep one Test per application and environment and reimport into it, so parameters drop off when fixed.
• Pin the Dalfox version in pipelines. The parser expects the 2.x JSON layout, and a major version change can alter the output.
• Tag imports with the environment and build (for example tags=staging,build-512) to tie findings to a deployment.