Same-origin policy

An origin is the tuple of scheme, host and port, as defined in RFC 6454 and in the WHATWG HTML and URL standards: https://a.example, http://a.example and https://a.example:8443 are three different origins, while two URLs differing only in path share one. Some documents get an opaque origin, for example sandboxed iframes and data: URLs; it serialises as the string "null" and is same-origin with nothing but itself. The policy arrived with JavaScript in Netscape Navigator 2.0 in 1995 and is really a family of rules applied to different APIs: script access to another window's DOM, reading responses from fetch or XMLHttpRequest, reading pixels from a canvas tainted by cross-origin images, and per-origin storage such as localStorage and IndexedDB, which browsers increasingly also partition by top-level site.

The asymmetry is the key design point. Cross-origin writes and embedding are allowed: a page may submit forms, follow links and embed images, scripts, stylesheets and frames from anywhere. Cross-origin reads are blocked. That is why JSONP worked, by embedding data as a script, and why cross-site script inclusion attacks against JSON endpoints existed. Controlled relaxation comes from CORS, specified in the WHATWG Fetch Standard: the server opts in with Access-Control-Allow-Origin; requests with non-simple methods or headers first trigger an OPTIONS preflight; and credentialed requests require an exact origin, not the wildcard, together with Access-Control-Allow-Credentials: true. Cross-window messaging uses postMessage, where the receiver must check event.origin. The old document.domain relaxation is deprecated and being removed from browsers.

CORS misconfigurations are a recurring finding: reflecting any Origin header together with credentials, trusting the "null" origin (which sandboxed attacker pages can produce), or validating origins with a suffix or regex match that also accepts evil-example.com. Another subtlety is the difference between origin and site, where site means scheme plus registrable domain from the Public Suffix List. SameSite cookies and Chrome's site isolation work on sites, so app.example.com and forgotten.example.com are cross-origin but same-site, and an XSS on the forgotten subdomain can undermine SameSite as a CSRF defence.

The policy has clear limits. It does not stop requests being sent, so CSRF remains possible; it cannot help once attacker script runs inside the trusted origin, which is XSS; and Spectre (2018) showed that data sharing a process with attacker code can leak through timing side channels regardless of any policy. Browsers responded with process-per-site isolation and opaque-response blocking, and pages that need high-resolution timers or SharedArrayBuffer must be cross-origin isolated using COOP: same-origin together with COEP: require-corp. Content Security Policy is complementary: it limits what a page may load and execute, not what it may read.