# Cross-origin credential and cookie selection

Cookie and credential lookups keyed on page origin instead of request target, leaking one origin's secrets to another

_Area: Web infrastructure and server-side requests. Seen in 3 disclosed reports; one confirmed bounty: $560; latest 2026-03-29. Updated 2026-11-02._

## How it works
A request carries two origins: the page that initiated it and the URL it is sent to. Cookies and credentials must be selected by the *request target* origin, because that is who the cookie belongs to. The weakness appears when code builds the cookie lookup from the page's own location (`window.location.href`) instead of the request URL. The assumption that breaks is "the cookie jar is queried with the destination"; once the page origin is substituted, origin A's cookies are attached to a request going to origin B, and B receives secrets it should never see.

## Where it shows up
- Fetch/HTTP client code that derives a URL for cookie lookup from `window.location`, `document.location`, or a stored page context rather than the outgoing request URL.
- Emulators and polyfills (DOM shims, headless browsers, test harnesses) that reimplement fetch, XHR, or redirect handling.
- Any `credentials: include` path where the cookie container is queried separately from where the request is sent.
- Redirect handling that re-evaluates cookies against the original page rather than the redirect destination.

## How to review
Find every call that reads cookies or credentials and check its argument. The invariant: the origin used to select cookies must equal the origin of the URL the request is actually sent to, and must be re-evaluated after each redirect. Trace the value passed into the cookie lookup back to its source; if it reaches `window.location` or any page-scoped variable, it is wrong. Confirm the request URL is what feeds the lookup, and that cross-origin requests only carry cookies belonging to the target.

## How finders spotted it
- Read `FetchRequestHeaderUtility.ts` and noticed `getCookies()` was called with an `originURL` built from `window.location.href` rather than the request URL, contradicting fetch spec cookie scoping [E1](https://bugbountylibrary.com/r/ghsa%3AGHSA-w4gp-fjgq-3q4g.md).

## Variants seen
- Browser-emulator fetch attaching page-origin cookies to a cross-origin request target [E1](https://bugbountylibrary.com/r/ghsa%3AGHSA-w4gp-fjgq-3q4g.md).

## Impact and severity
Origin A's cookies are disclosed to origin B, enabling session theft or cross-origin data exposure whenever an attacker controls the destination [E1](https://bugbountylibrary.com/r/ghsa%3AGHSA-w4gp-fjgq-3q4g.md). Severity rises with the sensitivity of the leaked cookies and how easily an attacker can steer a request to their domain.

## Seen in real software
Open-source packages and projects, and products, where this pattern was found. If the target runs one, compare the version it runs with the fix.
- **happy-dom (npm)** < 20.8.9, fixed in 20.8.9: Happy DOM's fetch credentials include uses page-origin cookies instead of target-origin cookies (CVE-2026-34226). Report: https://bugbountylibrary.com/r/ghsa%3AGHSA-w4gp-fjgq-3q4g.md. Fix: https://github.com/capricorn86/happy-dom/commit/68324c21d7b98f53f7bb5a7b3e185bda7106e751

## Evidence
- E1: https://bugbountylibrary.com/r/ghsa%3AGHSA-w4gp-fjgq-3q4g.md
- E2: https://bugbountylibrary.com/r/h1%3A1392211.md
- E3: https://bugbountylibrary.com/r/h1%3A1077022.md