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

cross-site-scriptingweb

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.

Sources & further reading

  1. Cross-site scripting ↗portswigger
  2. Content Security Policy ↗mdn

Content license: CC-BY-4.0. Source-derived sections retain their cited licenses and redistribution notices. How this reference is compiled →