REFERENCE GUIDE
Cross-site scripting and browser execution contexts
Cross-site scripting transfers untrusted data into an executable browser context.
Also known as: xss · DOM XSS
Mechanism
Cross-site scripting transfers untrusted data into an executable browser context. The escaping needed in an HTML text node differs from an attribute, JavaScript string, URL, or CSS value. A reflected marker helps locate the sink but does not establish execution. DOM-based cases may never appear in the server response because client-side code reads a fragment or other browser-controlled source.
Practical method
Insert a unique inert marker, inspect the raw response and the resulting DOM, and trace transformations between them. Identify the exact parser context before constructing a minimal local demonstration. Inspect content security policy, iframe sandboxing, and origin boundaries. For DOM cases, follow the source to the sink with developer-tools breakpoints rather than guessing payload families.
// Text rendering preserves data as data.
output.textContent = location.hash.slice(1);
// HTML parsing requires a deliberate sanitization policy.
// output.innerHTML = untrustedInput;
Interpreting evidence
Confirm which principal executes the script and which page state is accessible. A console message from a deliberately instrumented lab page establishes execution more clearly than a broken element. Record whether the sink is reflected, stored, or client-side.
Pitfalls and limits
Encoding once is not sufficient if another layer decodes it. Sanitization must match the final sink. HttpOnly limits cookie reads but does not prevent same-origin authenticated actions by an injected script.