Updated Jul 14, 2026

Vulnerabilities

Confirm reflected XSS on a parameterized URL

Tiny XSS check for GET and POST parameters on one URL.

Python

Agent

overview

What dsxs does

In a Trickest workflow, dsxs is a confirmation node for parameterized URLs: inject a marker, watch reflection, write FOLDER and FILE findings.

Use it when you suspect a reflected XSS point and want a yes-or-no on GET or POST params before opening a heavier XSS engine.

Inputs mirror dsss: -u, --data, --cookie, --referer, --user-agent, --proxy. Hits note no filtering versus some filtering so you know if evasion is still needed.

source github.com/stamparm/DSXS

use cases

Where dsxs fits

Confirm a reflected XSS point

Point dsxs at a parameterized URL to check whether a GET or POST parameter reflects an injected marker, a fast yes-or-no on a suspected flaw.

Reach parameters behind a session

Set the Cookie, Referer, and User-Agent headers so dsxs loads authenticated pages and tests the parameters that only appear once you are logged in.

Sweep a crawled URL set

Run dsxs over parameterized URLs from a crawler like gau or katana to flag the candidates worth a closer manual look.

Gauge how much filtering blocks a payload

Read the no-filtering or some-filtering note dsxs prints on each hit to judge whether a parameter reflects raw or needs an evasion payload to fire.

reference

dsxs inputs and flags

6 inputs
NameTypeFlagDescription
urlSTRING-uTarget URL, e.g. http://www.target.com/page.htm?id=1.
post-dataSTRING--dataPOST data to test, e.g. query=test.
cookieSTRING--cookieHTTP Cookie header value.
user-agentSTRING--user-agentHTTP User-Agent header value.
refererSTRING--refererHTTP Referer header value.
proxySTRING--proxyHTTP proxy address, e.g. http://127.0.0.1:8080.

Showing key inputs. dsxs exposes 6 inputs in total.

example

Run dsxs

dsxs · command
# test a reflected GET parameter and a POST form field on one endpoint
python dsxs.py -u "http://example.com/search?q=1" --data "comment=test" --cookie "PHPSESSID=1a2b3c"
sample output
 Damn Small XSS Scanner (DSXS) < 100 LoC (Lines of Code) #v0.3c
 by: Miroslav Stampar (@stamparm)

* scanning GET parameter 'q'
 (i) GET parameter 'q' appears to be XSS vulnerable (".xss.", pure text response, no filtering)
* scanning GET parameter 'category'
* scanning POST parameter 'search'

scan results: possible vulnerabilities found

guidance

Choosing dsxs

Use dsxs for a lightweight reflected XSS check on one parameterized URL. Sibling dsss covers SQLi the same way. For large payload libraries or multi-endpoint crawling, switch to a dedicated XSS engine.

dsss

Sibling damn-small scanner for SQL injection. Same minimal request shape, different vulnerability class.

airixss

Reflection-based XSS verification over a URL list. Better for high-volume confirmation than single-URL checks.

faq

dsxs questions

Reflected XSS. It injects a marker into each GET parameter and into POST parameters from --data, then checks whether the marker returns unescaped. Some versions also flag a risky page-level sink as XSS vulnerable (DOM).

Pass the body with --data, for example dsxs -u http://example.com/search --data "q=test". On Trickest, set the post-data node input instead of the flag.

Yes. Set --cookie for the session, plus --referer or --user-agent when a page or filter checks them. Those headers go on every request.

'no filtering' means the marker came back untouched, so a firing payload is often trivial. 'some filtering' means characters were stripped or encoded, so you may still need evasion.

dsxs checks one URL with a fixed payload set. For large payload libraries, filter evasion, or many endpoints, move to a dedicated engine such as dalfox. Use sibling dsss for SQL injection.

Run dsxs yourself

A target URL feeds dsxs, which tests its GET and POST parameters for cross-site scripting and writes the findings as a queryable output.

Facts on this page come from the live Trickest tool library.