Back-office Renderer Sinks
Find attacker-controlled records that are rendered later in support, moderation, reporting, export, or admin workflows, then prove the smallest safe execution or sensitive-action path.
Tags: admin, stored-xss, blind-xss, renderers, uploads
Level: advanced
Method
Map producer-to-reviewer flows
Inventory fields that cross a trust boundary: ticket text, profile data, names, filenames, CSV/PDF exports, webhook payload previews, markdown, import errors, audit events, and email-to-case ingestion. Identify who renders each field and in which product surface.
Tools: Burp Suite
Classify the renderer
Determine HTML, Markdown, rich text, template, CSV, PDF, image, or client-side framework rendering. Capture the exact encoding and sanitizer behavior with a unique inert marker before considering an execution probe.
Trace transforms and secondary sinks
Follow the stored value through APIs, notifications, exports, preview endpoints, and front-end bundles. Look for double decoding, unsafe HTML conversion, attachment previews, link unfurling, spreadsheet formula interpretation, and URL/image fetchers.
Validate safely
Use program-approved canaries or a benign marker on an account/record you own. Do not collect cookies, page content, credentials, or customer data. Demonstrate that a privileged reviewer context renders or acts on the record, not merely that input is stored.
Tools: interactsh
Report the boundary and impact
Show attacker role, reviewer role, exact rendering path, sanitization bypass if any, and a reproducible harmless proof. Separate an unconfirmed blind lead from verified execution or data/action impact.
Field notes
- A stored string is not XSS until a real renderer and context are proven.
- Exports can be high impact even when they never enter a browser; model the desktop or server-side consumer.