Browser execution, cross-origin reads, and forged actions

Use real browser behavior to distinguish XSS, CSRF, CORS, and messaging failures from header-only leads.

Used in these playbooks#

Setup and invariant

Use two controlled accounts and separate browser profiles. For cross-origin tests, use a researcher page and the local target on different ports; these are different origins but may still be the same site. For conclusions involving SameSite cookies, reproduce with genuinely different sites in an authorized HTTPS setup. Record browser version, cookie attributes, CSP, iframe sandboxing, request initiator, and navigation context.

The invariant is: a lower-trust origin or stored value cannot execute in the application origin, read protected responses, or cause an unauthorized credentialed action. Each of those outcomes is a separate test. XSS, CSRF, CORS.

Numbered test procedure

1. Map sources and sinks. Start with a distinctive text marker. Track it through reflected HTML, attributes, JavaScript strings, DOM insertion, Markdown preview, stored comments, embedded documents, and postMessage handlers. Record what is escaped and whether rendering occurs server-side or in JavaScript. Do not copy one payload across unrelated contexts.
2. Build a normal and inert control. As A, save plain text into a private object B is allowed to view. Verify B sees it. An HTML-escaped version is the inert comparison. For a local HTML text sink, a marker-only example is <img src=x onerror="document.documentElement.dataset.bb='BB-XSS-01'">. Inspect B's DOM for the resulting attribute; the payload never reads cookies or sends data. If CSP blocks execution, preserve that outcome instead of claiming execution.
3. Test CSRF delivery. Capture B's normal reversible preference change. From the controlled other origin, reproduce it using a browser-deliverable form or fetch request without a manually inserted target bearer token. Verify which cookies were actually sent, whether preflight occurred, and whether the setting changed in a fresh target tab. Use an invalid CSRF token or logged-out profile as a control. A manually edited HTTP request is not by itself a browser exploit.
4. Test CORS reads. From the researcher page, call a private test endpoint with credentials: 'include' and attempt to read the response body. Compare an allowed application origin, the researcher origin, and an anonymous request. Save the actual browser result and credential behavior. A request reaching the server is different from JavaScript reading its response; wildcard origins do not enable credentialed response access. Browser CORS behavior.
5. Test messages and embedding where present. For an observed postMessage handler, send the expected message shape from your controlled page and change only the sender origin. Verify a harmless state marker or a restricted action on your account. For iframe interaction, prove the sensitive action is practically inducible, rather than reporting absent framing headers alone.
6. Interpret delivery and cleanup. Record which account planted content, which viewed it, the effective origin, and the boundary crossed. Remove stored payloads and reverse preference changes. A payload that only executes after the tester pastes JavaScript into DevTools has not established an application injection path.

Command card

Create browser-probe/index.html locally with this content, then serve it using the command below. Open it while the separate controlled target session exists; confirm that your browser's cookie policy permits the intended experiment.

<!doctype html><meta charset="utf-8"><pre id="result"></pre>
<script>
fetch('http://127.0.0.1:8000/api/me', {credentials: 'include'})
  .then(r => r.text())
  .then(t => { document.querySelector('#result').textContent = t; })
  .catch(() => { document.querySelector('#result').textContent = 'Read blocked or request failed'; });
</script>

python3 -m http.server 8766 --bind 127.0.0.1 --directory browser-probe

Report threshold and checklist

Report cross-user execution, a browser-readable private response, or a forged protected state change with realistic delivery. Reflection, arbitrary Origin acceptance in curl, missing CSRF tokens, and same-site laboratory results generalized to cross-site attacks are common false positives.

• Real browser reproduces the claimed behavior.
• Origin and site relationships recorded separately.
• Credentials, CSP, preflight, and redirects observed.
• Benign marker demonstrates only the required impact.
• Stored content and account settings cleaned up.

Vulnerability reverse references#

• Reflected or stored cross-site scripting — Attacker-controlled input executes in another controlled user’s browser under the application origin.
• DOM-based cross-site scripting — Browser-side code moves attacker-controlled data into an executable DOM or script sink.
• Cross-site request forgery (CSRF) — A browser can be induced to perform a protected state change using ambient credentials.
• CORS private-data exposure — A lower-trust origin can read a protected response using the controlled user’s browser credentials.
• Cross-origin messaging trust failure — A message handler trusts an unauthorized sender or leaks protected data to an unintended origin.
• Unsafe upload interpretation or placement — Uploaded content is handled in a security-sensitive context beyond its permitted file contract.
• Cross-site WebSocket hijacking — A page on another origin opens an authenticated socket and reads or performs protected operations.
• Untrusted WebView content reaches a native bridge — A page or frame controlled outside the trusted app origin can invoke native capabilities through a shipped WebView bridge.
• Electron IPC exposes main-process authority to an untrusted sender — An attacker-controlled renderer or frame invokes a privileged main-process operation through insufficient sender or argument validation.
• Open redirect across an origin trust boundary — Attacker input controls a navigation destination that the application treats as trusted.
• Clickjacking of a sensitive authenticated action — An untrusted origin can frame and visually disguise an authenticated operation.
• Page message borrows unintended browser-extension authority — An ordinary web page reaches a privileged extension action through insufficient message sender or argument validation.

Nearby shared procedures#

Object, function, and property authorization · Authentication, recovery, federation, and session lifecycle · Trace input into queries, commands, and templates · Server-side fetching and network trust boundaries · Uploads, downloads, paths, archives, and XML · Workflow invariants, replay, idempotency, and races · REST, GraphQL, gRPC, WebSocket, and SSE permission parity · Proxy normalization, cache isolation, and request boundaries