Post cover image
Photo by Annie Spratt on Unsplash

July 15, 2026

This Tool Found An XSS Bug In 40 Seconds That I Missed Manually For An Hour

Why Dalfox became my go-to XSS scanner, and every command you need to actually use it right

By Yamini Yadav_369

7 min read

I spent almost an hour manually testing input fields on a target, trying different payloads, checking the response, tweaking, and trying again. Nothing was landing. I was about to mark the field as clean and move on.

Then I ran Dalfox against the same URL just to double-check myself. Forty seconds later it flagged a working XSS payload on a parameter I had tested manually but with the wrong encoding. I had been so close the whole time, but Dalfox caught the exact combination I had not tried yet, and it did it faster than I could type out one more manual attempt.

That is the moment I stopped treating XSS testing as purely a manual game. Dalfox does not replace understanding how XSS works, but it removes the slow trial-and-error part and lets you focus on confirming and exploiting what it finds. Let me walk you through exactly what this tool does, how it works, and every command you actually need.

What Is Dalfox

Dalfox stands for DOM-based Advanced Layer Fingerable XSS. It is an open source tool built specifically for finding and confirming XSS vulnerabilities, whether that is reflected XSS, stored XSS, or DOM-based XSS.

Think of it like this. Manually testing for XSS means trying payload after payload, checking if it gets reflected back, checking if it survives filtering, and checking if it actually executes. Dalfox automates that entire cycle. It sends a wide range of payloads, checks how the application handles each one, tests for filter bypasses, and tells you exactly which ones actually worked.

What sets Dalfox apart from just throwing generic payload lists at a target is that it is context-aware. It looks at where your input lands in the page, whether that is inside an HTML tag, inside a JavaScript block, or inside an attribute, and adjusts its testing approach based on that context instead of blindly firing the same payloads everywhere.

Why This Tool Matters So Much

XSS remains one of the most common vulnerabilities found in bug bounty programs and pentests, but it is also one of the most time-consuming to test manually when you are covering a large number of parameters across a big application.

Manual testing works, but it does not scale. If a target has fifty parameters across different pages, manually trying reflected, stored, and DOM-based payloads on each one takes hours. Dalfox lets you point it at a large set of URLs and get back a filtered list of what is actually worth your manual attention, instead of spending that time yourself on parameters that turn out clean.

It also catches things a rushed manual test might miss, since it systematically tries filter bypass techniques and different encoding approaches that most testers do not have the patience to try one by one under time pressure.

How Dalfox Actually Works

Let us slow down and understand the mechanics here, since knowing this will help you interpret results much better.

Parameter discovery: Dalfox first identifies the parameters in a URL or form that could potentially reflect user input back into the page.

Payload injection: It then injects a series of test payloads into each parameter, ranging from simple ones to more advanced encoded and obfuscated variants designed to slip past basic filters.

Reflection and context analysis: For each payload sent, Dalfox checks how and where the response reflects that input. It looks at whether the input lands inside a script tag, an HTML attribute, a comment, or plain text, since each context requires a different kind of payload to actually execute.

Filter bypass attempts: If a basic payload gets blocked or sanitized, Dalfox does not just give up. It tries encoding tricks, case variations, and alternate syntax that sometimes slip past weak filtering logic.

Verification through headless browser: For confirming actual execution rather than just reflection, Dalfox can use a headless browser to check if the payload actually fires as real JavaScript execution, not just appears in the raw response text. This step is what separates a confirmed finding from a false positive.

Installing Dalfox

Dalfox is written in Go, so make sure Go is set up first.

go install github.com/hahwul/dalfox/v2@latest

Confirm the install worked:

dalfox version

If a version number prints back, you are ready to scan.

Let us go through these one at a time so you understand exactly what each command is doing.

1. Scanning a single URL

Command:

dalfox url https://example.com/search?q=test

What it means in plain English: "Take this URL, test every parameter you can find in it, and tell me if any of them are vulnerable to XSS."

When to use it: This is your basic starting point whenever you have one specific URL with a parameter you want checked.

2. Scanning a list of URLs

Command:

dalfox file urls.txt

What it means: "Here is a file with a list of URLs, one per line. Go test every single one of them for XSS."

When to use it: Perfect after you have already gathered a big list of URLs using tools like gau or waybackurls, and now you want to check all of them for XSS in one batch instead of one at a time.

3. Saving results to a file

Command:

dalfox url https://example.com/search?q=test -o results.txt

What it means: "Run the scan, but save the findings into results.txt instead of just showing them on my screen."

When to use it: Always do this so you have a proper record you can review later or attach to your report.

Command:

dalfox url https://example.com/dashboard --cookie "session=abc123"

What it means: "Run the scan on this URL, but include my session cookie so you are testing as a logged in user, not as an anonymous visitor."

When to use it: Essential for testing pages behind a login. Many real XSS vulnerabilities exist on authenticated pages that never get tested if you only scan as an anonymous user.

5. Adding custom headers

Command:

dalfox url https://example.com/api --header "Authorization: Bearer mytoken"

What it means: "Run the scan, but include this authorization header with every request, just like a real authenticated API call would."

When to use it: Needed when testing APIs or applications that use token based authentication instead of cookies.

6. Using a custom payload list

Command:

dalfox url https://example.com/search?q=test --custom-payload mypayloads.txt

What it means: "Test this URL, but instead of only using your built in payloads, also try every payload from my custom file."

When to use it: Great when you have specific payloads known to work against a particular framework or filtering pattern you have seen before.

7. Setting the request delay

Command:

dalfox url https://example.com/search?q=test --delay 300

What it means: "Wait 300 milliseconds between each request instead of firing them as fast as possible."

When to use it: Important on client engagements where sending requests too fast could overload the server or trigger rate limiting and monitoring alerts.

8. Filtering out false positives with blind XSS testing

Command:

dalfox url https://example.com/contact --blind https://yourcallback.xss.ht

What it means: "Test this form, and if any payload triggers somewhere later, like an admin viewing a support ticket, ping this callback URL so I know about it even if I am not watching in real time."

When to use it: Extremely useful for stored XSS that only executes later, when someone else like an admin views the submitted data. Blind XSS testing catches these delayed executions that a normal scan would completely miss.

9. Scanning with a specific HTTP method

Command:

dalfox url https://example.com/api/update --method POST --data "name=test&email=test@test.com"

What it means: "Test this endpoint, but send the request as a POST with this specific data in the body, instead of the default GET request."

When to use it: Needed whenever the vulnerable input is submitted through a POST request, like a form submission or an API call that does not accept GET.

10. Running a mass scan across multiple domains

Command:

dalfox file domains.txt --format json -o results.json

What it means: "Take this list of URLs, test them all, and save the entire output in JSON format into results.json instead of plain text."

When to use it: Best when you plan to process the output afterward with a script, or feed it into a dashboard or reporting pipeline.

11. Skipping specific parameters

Command:

dalfox url https://example.com/page?id=1&token=abc --ignore-return 302,404

What it means: "Test this URL, but ignore any responses that come back as a 302 redirect or a 404 not found, since those are not useful for finding XSS."

When to use it: Cleans up your results by cutting out noise from responses that could never actually reflect a working payload anyway.

12. Combining with gau for full domain coverage

Command:

echo example.com | gau | grep "=" | dalfox pipe

What it means: "Pull every archived URL for this domain, keep only the ones that have parameters in them, and pipe that whole list directly into Dalfox for testing."

When to use it: This combination is one of the fastest ways to go from zero to a fully tested list of parameterized URLs on a target, combining recon and vulnerability testing in a single chained command.

Here is how I actually use Dalfox on a real engagement, step by step.

  1. Gather a big list of URLs using gau or waybackurls first.
  2. Filter that list down to only URLs containing parameters, since those are the only ones worth testing for XSS.
  3. Pipe the filtered list directly into Dalfox for a mass scan.
  4. Set a reasonable delay if this is a client engagement where request rate matters.
  5. Add authentication cookies or headers if the target has areas behind a login worth testing.
  6. Set up blind XSS callbacks for any forms that submit data an admin or another user might view later.
  7. Review the flagged findings manually to confirm real impact before writing anything into a report.

This flow takes what used to be hours of manual parameter testing and turns it into a much faster, much wider pass across the whole target, while still leaving room for the manual verification that actually matters for a solid report.

The biggest mistake is running Dalfox at full speed on a live client engagement without setting a delay. Firing too many requests too fast can overload a server or get your IP blocked mid-scan.

Another common mistake is only testing as an anonymous user and skipping authenticated pages entirely. A huge amount of real-world XSS lives behind a login, and missing the cookie or header flag means missing that whole section of the application.

People also tend to trust every flagged result as a confirmed vulnerability without manually verifying it. Dalfox is very good, but manual confirmation still matters before you write up a finding, especially for anything that could be a false positive from unusual response formatting.

Dalfox does not replace understanding how XSS actually works, and it should not be treated that way. What it does is take the slow, repetitive part of testing, trying payload after payload across dozens of parameters, and compresses it down into something you can run in minutes instead of hours. That time savings lets you spend more energy on manual verification and creative testing where it actually matters.

Set your delay properly, always test authenticated areas, use blind XSS for anything that submits data for later viewing, and manually confirm before reporting. Do this consistently and Dalfox becomes one of the most efficient tools in your entire testing workflow.

If this helped you understand Dalfox better, follow The First Digit for more practical security tool breakdowns written the way they should be, simple, honest, and based on real testing experience.