CORS misconfiguration is consent, not an exploit

Cross-origin resource sharing is not a vulnerability class. It is a permission model, and the server grants the permission. CORS exists to relax the Same-Origin Policy on purpose. When it is misconfigured, the server instructs the attacker’s browser context that reading authenticated response bodies is permitted. The browser complies. That is the whole failure. No memory corruption. No exploit primitive. A header value that should never have been reflected, reflected.

The Same-Origin Policy is the boundary. Scheme, host, port - all three must match. A script loaded from https://app.example.com can issue a request to https://api.example.com but cannot read the response unless the responding server opts in. CORS is that opt-in. Two response headers carry the decision. Access-Control-Allow-Origin names the single origin permitted to read the response. Access-Control-Allow-Credentials declares whether cookies and HTTP authentication ride along, and whether the credentialed response may be read by the calling script.

The specification forbids the one combination developers reach for first. Access-Control-Allow-Origin: * paired with Access-Control-Allow-Credentials: true is rejected by every conformant browser. The wildcard cannot be credentialed - the Fetch standard treats it as a hard contradiction. Developers hit this wall during integration and route around it. They read the inbound Origin request header and echo it back verbatim into Access-Control-Allow-Origin, then set Access-Control-Allow-Credentials: true to make the cookie-bearing request work. The allowlist is now every origin that asks. The Origin header is attacker-controlled. The server has delegated its trust decision to the client making the request.

That is the dominant failure mode: origin reflection. The server treats the Origin header as an assertion of identity rather than an attacker-supplied string. It is the same category error as trusting X-Forwarded-For for access control. CWE-346, origin validation error. The mechanism is a missing comparison. The server should match Origin against a fixed allowlist and emit a static Access-Control-Allow-Origin only on an exact match. Instead it emits whatever arrived. A request from https://attacker.tld returns Access-Control-Allow-Origin: https://attacker.tld and Access-Control-Allow-Credentials: true. The attacker’s page is now authorised to read the victim’s authenticated responses.

Reflection is not the only variant. The null origin is the second. Browsers send Origin: null from sandboxed iframes, data: and file: documents, and redirects that cross opaque-origin boundaries. Allowlists frequently include null because a developer saw it in a log and added it to stop a console error. Any page can produce a null origin by hosting the request inside a sandboxed iframe. An allowlisted null is an allowlist of everyone. The trust check passes because the string matches - the string was never identity.

The third variant is broken matching logic. Developers who do build an allowlist often build it wrong. Origin.startsWith("https://example.com") matches https://example.com.attacker.tld. Origin.endsWith("example.com") matches https://notexample.com and https://evilexample.com. An unanchored regular expression - https://.*\.example\.com without ^ and $ and without escaping the dot - matches https://example.com.attacker.tld and https://exampleXcom. The dot that was meant to be literal matches any character. Each of these is a parser-level mismatch between what the developer believed the check asserted and what it actually asserted. The attacker registers or controls a hostname that satisfies the flawed predicate. CWE-942, permissive cross-domain policy with untrusted domains.

The exploit path requires no server compromise. The attacker hosts a page. The victim, already authenticated to the target with a live session cookie, loads that page through phishing, a malicious advertisement, or a watering hole - MITRE T1189, drive-by compromise, for the delivery. The attacker’s script issues a credentialed cross-origin request to the target API. The victim’s browser attaches the session cookie automatically because the request runs in the victim’s browser with the victim’s cookie jar. The target reflects the origin, allows credentials, and returns the authenticated response. The Same-Origin Policy would normally block the script from reading that response. The CORS headers told the browser to permit the read. The script now holds the response body and exfiltrates it to attacker-controlled infrastructure.

What the script reads is the impact. Account data. API responses containing bearer tokens or API keys in the body. Anti-CSRF tokens, which collapses the CSRF defence and chains into authenticated state-changing requests. Internal service responses where the API is meant to be reachable only from a first-party front end. This is browser session hijacking - MITRE T1185 - using the victim as an authenticated proxy. The attacker never possesses the cookie; HttpOnly keeps the cookie itself out of script reach. The attacker possesses everything the cookie unlocks. Tokens harvested from response bodies feed directly into lateral movement: replay against other endpoints, T1550 use of alternate authentication material, T1606 forge web credentials where the leaked secret permits it. Initial access and credential access in a single cross-origin read.

This is documented exploitation, not theory. PortSwigger’s James Kettle published the canonical breakdown - “Exploiting CORS Misconfigurations for Bitcoins and Bounties” - in 2016, and the pattern has been a standing bug-bounty staple since. The class is tracked across hundreds of advisories under CWE-346 and CWE-942, spanning API gateways, SaaS dashboards, and self-hosted applications that added permissive CORS to make a single-page front end work. The 2019 framing holds because nothing about the mechanism changed - the spec did not move, the browsers did not move, and developers kept reflecting the Origin header to silence a preflight failure. Okta, Meta, and Cloudflare all publish guidance on exact-match origin validation precisely because the reflective shortcut keeps reappearing in code review.

The telemetry reality is the part defenders miss. A CORS attack produces almost nothing on the server side that looks abnormal. The cross-origin request arrives from the victim’s IP, carries the victim’s valid session, and hits a legitimate endpoint with legitimate parameters. There is no process anomaly for an EDR to surface - the execution is entirely inside the victim’s browser, against a sanctioned application, over TLS. Sysmon sees nothing; no child process spawns, no LSASS access, no injection. The web server sees a successful authenticated request. The only signal present is the Origin request header, and the standard Common Log Format does not record it. The single field that distinguishes attacker from user is the field most deployments never log.

Detection therefore has to be engineered deliberately at the edge. Log the Origin header on every request at the reverse proxy or WAF, alongside Referer. Build the SIEM correlation against the response, not the request: alert when Access-Control-Allow-Origin returns a value outside the known-good allowlist while Access-Control-Allow-Credentials is true. That condition is the misconfiguration firing in production and is observable on the response path if the proxy inspects outbound headers. A second rule flags credentialed requests where Origin is absent from the first-party set or equals null. Preflight OPTIONS requests carrying foreign origins are a weak indicator - useful, but simple requests under the Fetch definition skip preflight entirely, so absence of an OPTIONS proves nothing. WAF signatures key on payload patterns and almost never inspect Origin against an allowlist by default. That is the blind spot: the control plane treats Origin as metadata, and the attack lives in metadata.

The closing reality is that there is no patch boundary here, because there is no patch. CORS misconfiguration is a configuration state, not a code defect with a fixed version range. The correction is an exact-string allowlist evaluated server-side, a static Access-Control-Allow-Origin emitted only on match, Access-Control-Allow-Credentials set to true only where a credentialed cross-origin read is genuinely required, and null never present in the allowlist. Residual exposure persists wherever a service still reflects the Origin header, wherever a regex is unanchored, and wherever a trusted subdomain is vulnerable to takeover - a hijacked *.example.com host inherits the parent’s CORS trust and turns a same-site allowlist into an open one. The vulnerability was never in the protocol. The protocol does exactly what it is told. The defect is that it was told to trust the origin the attacker sends.