Quick test get or cookie parameter for xss?

[onesign12]

How to test cookie parameter for XSS?

[khalfanohaikal-cyber]

Buka website target ,buka dev tools f12 tab aplication cookies,cari cookies mencurigakan username, theme, lang

[adilburaksen]

Use --cookie for that:

dalfox "https://target.com" --cookie "param_to_test=value"

dalfox fuzzes each cookie value automatically. If you want to isolate a specific param, pass the others as static values:

dalfox "https://target.com" --cookie "session=abc123; vulnerable_param=FUZZ"

For GET params with cookies for auth, just put the params in the URL normally:

dalfox "https://target.com?search=value" --cookie "session=yoursessionhere"

If the XSS isn't reflected on the same page (stored/blind), add -b with your callback endpoint.

[TrueNix]

There are two separate questions here: how to test GET parameters and how to test cookie parameters. Dalfox handles both, but the approach differs.

GET parameters (in the URL query string)

Just put the params in the URL. Dalfox auto-discovers and fuzzes them:

dalfox "https://target.com/search?q=test&page=1"

To isolate a single parameter (skip the others), use --param / -p:

dalfox "https://target.com/search?q=test&page=1" -p q

If the endpoint needs auth, pass your session cookie alongside:

dalfox "https://target.com/search?q=test" --cookie "session=abc123"

Cookie parameters

Dalfox can fuzz cookie values directly. Use --cookie (repeatable) to supply cookies; Dalfox treats each cookie value as a fuzzable parameter:

dalfox "https://target.com" --cookie "username=test" --cookie "theme=dark"

To isolate a specific cookie param while keeping others static, use the name:location syntax with --param:

dalfox "https://target.com" --cookie "session=abc123; username=FUZZ" -p "username:cookie"

This tells Dalfox: fuzz the username cookie value, keep session as-is.

Skip cookie reflection checks if needed

If the target doesn't reflect cookie values in the response (common for stored contexts), add --skip-reflection-cookie so Dalfox doesn't waste requests checking for reflection:

dalfox "https://target.com" --cookie "data=FUZZ" --skip-reflection-cookie

Blind XSS (cookie or param, fired elsewhere)

If the cookie value is consumed server-side and rendered in an admin panel or different page, use blind XSS callbacks:

# With a callback URL
dalfox "https://target.com" --cookie "username=FUZZ" -b https://your-callback.example

# Or use interactsh OOB for server-side detection without a callback server
dalfox "https://target.com" --cookie "username=FUZZ" --blind-oob

Quick summary

Scenario	Command
GET params, no auth	dalfox "https://target.com?q=test"
GET params with auth	dalfox "https://target.com?q=test" --cookie "session=abc"
Cookie param fuzzing	dalfox "https://target.com" --cookie "username=test"
Isolate one cookie param	-p "username:cookie"
Blind XSS via cookie	--cookie "x=FUZZ" -b https://callback

The key insight: Dalfox treats cookie values as first-class parameters, not just auth tokens. If you can control a cookie value that ends up rendered somewhere, it's fuzzable just like a GET param.