REFERENCE GUIDE

CORS and cross-origin response access

CORS lets a server permit browser scripts from another origin to read responses.

Also known as: cross-origin resource sharing

cors-policyweb

Mechanism

CORS lets a server permit browser scripts from another origin to read responses. It controls response access rather than preventing all requests. A policy error becomes consequential when an attacker-controlled origin can read sensitive authenticated data, often through overly broad origin reflection combined with credentials. Origin includes scheme, host, and port.

Practical method

Inspect Access-Control-Allow-Origin and Access-Control-Allow-Credentials on a sensitive lab endpoint. Compare a trusted origin, a controlled untrusted origin, and null only if the application supports that case. Reproduce the browser fetch with realistic cookie settings and distinguish simple requests from preflighted requests.

fetch("https://lab.example/profile", { credentials: "include" })
  .then(response => response.text());

Interpreting evidence

The browser must make the response body available to the initiating script. Headers that look permissive may still fail browser validation or receive no credentials because of cookie restrictions.

Pitfalls and limits

A wildcard origin does not allow credentialed reads under standard CORS rules. SameSite can limit cookie attachment. Suffix or substring origin checks can accept unintended hosts.

Sources & further reading

  1. CORS ↗mdn
  2. CORS ↗portswigger

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