Blind XSS: Stop Thinking About Payloads, Start Thinking About People

Hello, I am Nitin.

Day twenty-five. Yesterday you built the listener. Today you decide where to plant.

And I want to start by correcting the instinct almost everyone has, because it is the difference between callbacks and silence.

When people start with blind XSS, they think about payloads. Which vector, which encoding, which clever construction. They spend an evening perfecting one payload and put it in three fields.

That is backwards. With blind XSS you cannot see whether your payload worked, so cleverness buys you nothing you can measure. What you can control is how many places a privileged human might eventually read your text.

So the right question is not "what should I inject?" It is:

Who inside this company will eventually read something I typed, and in what tool?

Answer that properly and the payload almost does not matter. Answer it badly and the most elegant payload in the world sits in a database nobody ever renders.

Coverage beats cleverness. Every time.

The mental model: follow the human

Every company runs on internal tooling that exists to look at customer data. Someone has to read the support ticket. Someone has to approve the refund. Someone has to check the flagged account. Someone reads the error dashboard when the alerts fire.

Those tools were built fast, for a small internal audience, by teams who reasonably assumed the data flowing into them came from their own product. They frequently pre-date the security programme entirely. They are almost never in scope for a pentest because they are not public. And the data they display is your input, arriving from the public product they trust.

That gap — untrusted input rendered in a trusted internal tool — is the whole opportunity.

So walk through the company as an organisation chart rather than a website. Support. Billing. Trust and safety. Compliance. Engineering. Sales. For each one, ask what they read, and how your text could reach it.

Surface one: support, the classic

The highest-probability surface in almost every product, because contacting support is a feature designed to put your words in front of an employee.

Plant in:

• Ticket subject and body. The subject especially — it renders in the queue list, which every agent sees, before anyone opens anything.
• Attachment filenames. Day twenty-three's vector, delivered straight to a support console.
• The name and company on the account raising the ticket, which the agent's view displays alongside it.
• Follow-up replies, which sometimes render through a different path from the original.
• Live chat messages, including ones sent while no agent is connected — those get queued and read later.
• Feedback and survey responses, which land in a review tool nobody thinks about.
• Bug report forms, which are read by engineers in tooling built even more casually than support's.

One practical note on being decent about this: write a real, sensible support ticket with your marker in it. Something a human can read, understand, and close politely. An agent's day should not be worse because you were testing.

Surface two: headers, the one nobody escapes

This is my favourite, because the entire path is invisible in the product's interface.

Every request you send carries headers. Applications log them. Logs get rendered — in analytics dashboards, security tooling, fraud review screens, session replay, and error trackers.

Nobody thinks of a header as user input. It arrives from a browser, it looks machine-generated, and it is written straight into a log record that something later displays.

Plant in:

• User-Agent, the classic
• Referer
• The forwarded-for and client-IP style headers, which frequently render in security and fraud tooling
• Accept-Language
• Any custom header the application's own JavaScript sends, which you can see from day nine's bundle work and modify

The delivery is trivial: set them in your proxy with a match-and-replace rule and browse the application normally for a while. Every request carries your marker, into every log the application keeps.

Where these land is what makes them valuable: error dashboards, fraud queues, analytics panels, and session-replay tooling are all read by people with elevated access, and none of those tools were built expecting hostile input.

Surface three: account and profile fields

Your own account details render in the internal customer view whenever anyone looks you up.

• Name fields, especially separate first and last name fields which are sometimes concatenated unescaped
• Company or organisation name
• Address lines, particularly the second line, which is free text
• Phone number, which is often stored as a string
• Job title, website, and biography
• Billing and tax reference fields
• Referral codes and promotional codes you supply

Then cause a reason for someone to look at your account. Raise a billing question, request a refund, trigger a verification. The field alone is not enough; something has to make a human open your record.

That combination — plant the field, then create the reason — is the technique most people miss. A payload in a profile field that nobody ever views is not a finding.

Surface four: workflow and review queues

Anything that routes your action to a human for a decision. These are high-value because the reviewing tools are usually internal, and the reviewers usually have authority to change things.

• Refund, chargeback, and dispute reasons
• Content reports and abuse reports, which land in moderation tooling
• Account verification submissions, including the free-text fields alongside documents
• Appeals against a restriction
• Seller, partner, or vendor applications
• Anything with an approval step

Submitting a report about your own second account is a clean, honest way to reach a moderation queue without involving anyone else's content.

Surface five: machines that render later

Text that is not shown in any interface but gets rendered by something downstream.

• Invoices and receipts, frequently generated as documents from account fields
• Email templates, where your name appears in a message rendered by a support agent's client or an internal web view
• Scheduled reports and exports sent to internal recipients
• Analytics and business-intelligence dashboards, which read the same database and render it in a completely different tool
• Audit logs, which record your actions with your values and are read during investigations
• Webhook and integration payloads delivered to an internal system

Day six told you to map every render surface. This is that exercise aimed specifically at the surfaces you cannot see.

Running a campaign properly

Blind XSS is a campaign, not a test. Here is how I run one.

One. Build the target's org chart. Before injecting anything, list the internal functions that plausibly exist: support, billing, moderation, compliance, engineering. Five minutes with the product and its help pages tells you most of it.

Two. For each function, list how your text reaches them. That is your injection point list. Aim for breadth — twenty shallow plants beat three deep ones.

Three. Assign an identifier to every single one, using yesterday's scheme. Target, field, date. Write it down before you inject, not after.

Four. Plant in one pass, methodically, keeping the record as you go.

Five. Create the reasons. Plants that need a human trigger — profile fields, account details — need an action that makes someone look. Raise the ticket, request the refund, submit the verification.

Six. Walk away. Genuinely. Go work on another target. The callback finds you.

Seven. Keep the infrastructure alive for weeks. Queues are slow. My eleven-day callback was not unusual.

Eight. Track what is outstanding. Your identifier file is an inventory of live content sitting in other people's systems, and you are responsible for it.

What silence actually means

No callback does not mean no vulnerability. It means one of these, and you cannot tell which from outside:

• Nobody opened the page yet
• The field was escaped correctly
• Your payload was truncated below the length needed
• Your domain was blocked at their network perimeter
• The tool has a content policy that blocked the load
• The value never reached a rendering surface at all

Because you cannot distinguish these, do not report speculatively. No callback is not a finding. It is an absence of evidence, and reporting absence as presence is how researchers lose credibility with a programme.

What you can do is improve coverage on the next pass. More surfaces, more variety in payload shape, different callback domains if you suspect blocking.

Impact ladder

• Informational — planted, no callback. Nothing to report.
• Medium — fires in a context no more privileged than your own.
• High — fires in an internal or staff-facing tool.
• Critical — fires in an administrative interface, or in a context that spans multiple customers' data.

The line that makes the severity clear in a report: an employee did their ordinary job — opened a ticket, reviewed a queue, looked at a dashboard — and my code ran in their session inside tooling built for privileged operations. No unusual action on their part. No social engineering. Just their normal work.

Conclusion — steal this checklist

• Stop thinking about payloads. Ask who inside this company will eventually read something I typed, and in what tool.
• Coverage beats cleverness. Twenty shallow plants beat three perfect ones.
• Internal tools were built fast, for a trusted audience, from data the team assumed was safe. That is the whole opportunity.
• Walk the organisation, not the website: support, billing, trust and safety, compliance, engineering.
• Support is the highest-probability surface, and the subject line renders in the queue before anyone opens the ticket.
• Headers are the surface nobody escapes. Set them in your proxy and browse normally; they land in dashboards, fraud tooling, and error trackers.
• Profile fields need a reason for someone to look. Plant the field, then raise the ticket. One without the other is not a finding.
• Workflow queues — refunds, disputes, moderation, verification — are read by people with authority to change things.
• Machine surfaces matter: invoices, email templates, exports, analytics, audit logs.
• Write real, readable tickets. An agent's day should not be worse because you were testing.
• Identifier before injection, always. Callbacks you cannot trace are bounties you lose.
• Silence proves nothing and is not reportable. Improve coverage instead of speculating.
• Keep infrastructure alive for weeks, and track what you have outstanding in other people's systems.

Tomorrow: XSS in AI interfaces, where model output has quietly become the newest untrusted input.

If you Love reading my blogs. Check my Youtube Channel too.