Back-Office and Renderer Sink Mapping
Trace tickets, emails, logs, exports, and uploaded metadata into browser and server-side renderers without assuming every callback came from an administrator.
Every step requires authorization. Review side effects before running commands against a live system.
Define the boundary before the test.
- Preconditions
- Current scope, observed technology, reachable feature, controlled identities or data, and a recovery plan.
- Expected evidence
- One observable response, state, or callback that distinguishes the hypothesis from normal behavior.
- Negative control
- The same action with the security-sensitive variable removed, replaced, or bound to its rightful owner.
- False-positive checks
- Cache, retry, race, reflection, proxy rewriting, stale sessions, and unrelated asynchronous activity.
- Chain gate
- Record the proven primitive and the next missing prerequisite. Do not expand impact until scope and authorization still permit the next step.
List back-office ingestion channels
Map support forms, inbound email, CRM synchronization, moderation queues, audit logs, exception dashboards, analytics labels, uploaded filenames and metadata, CSV exports, PDF generation, and notification templates. Confirm which channels are in scope before planting any marker.
Use channel-specific inert markers
Place a unique alphanumeric canary in one controlled record and one field. Include the channel, record, and field in the marker. Track transformations such as truncation, HTML encoding, Markdown conversion, CSV quoting, and template interpolation.
BO017_SUPPORT_SUBJECTProbe passive rendering
When markup testing is allowed, use a no-referrer image callback to learn whether a renderer interprets HTML and permits external images. Treat that as renderer evidence only. It does not prove JavaScript, a human viewer, or a privileged session.
<img referrerpolicy=no-referrer src=https://bo017-render.UNIQUE.oast.example/pixel>Probe execution separately
Only after the render context is supported and the policy allows it, use a callback-only event payload with a different token. The callback must not read page or user data. Avoid payloads that persist across shared dashboards or notify multiple users.
<svg onload="i=new Image;i.referrerPolicy='no-referrer';i.src='https://bo017-exec.UNIQUE.oast.example/js'"></svg>Identify the likely viewer
Use protocol, source network, user agent, time delay, path, recall action, and repeat controls to distinguish mail security scanners, headless PDF services, image proxies, server-side sanitizers, ordinary browsers, and staff dashboards. Label identity or privilege as unknown unless independently observed.
Minimize and clean up
Stop at one reproducible callback path, remove the test record where possible, and report the source-to-sink route plus controls. Do not collect cookies, DOM content, current URL, referrer, form values, tokens, or screenshots from the viewer.
Common guidance
- External image loading can happen in a mail gateway or PDF renderer that cannot execute your JavaScript.
- A privileged viewer is an impact hypothesis until the viewer role is evidenced.
- Filenames, EXIF fields, email display names, subjects, user agents, and Referer values can enter back-office systems through different encoders.
- One controlled record prevents a blind XSS test from becoming a persistent surprise for unrelated users.
Mapped workflow tools
References
- https://portswigger.net/kb/issues/00200100_cross-site-scripting-stored ↗
- https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/07-Input_Validation_Testing/02-Testing_for_Stored_Cross_Site_Scripting ↗
- https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/14-Testing_for_Incubated_Vulnerability ↗
Version history: normalized permanent page created 2026-08-20.