Same-Origin Policy (SOP).

The Same-Origin Policy is the foundational isolation boundary of the web, first shipped in Netscape Navigator 2 (1995). Two URLs share an origin only when their scheme, host, and port all match; otherwise the browser blocks scripts from reading responses, accessing the DOM of cross-origin frames, or inspecting cookies that belong to another site. SOP prevents a malicious page from silently reading the contents of a banking session opened in another tab.

What SOP does and does not cover

SOP governs reads, not sends: a page can still trigger cross-origin requests (a <form> POST, an <img> load), which is exactly why CSRF exists as a separate class of bug. It is selectively relaxed by CORS (defined in the WHATWG Fetch standard), postMessage, document.domain, and the legacy JSONP pattern. Overly permissive exceptions — for example reflecting Access-Control-Allow-Origin back from the request while also sending Access-Control-Allow-Credentials: true — are a frequent root cause of cross-origin data leakage and authentication bypass.

Hardening beyond SOP

The 2018 Spectre side-channel disclosures showed that SOP alone could not stop one origin from reading another's memory inside a shared renderer process. Chrome 67 responded by enabling Site Isolation by default, putting each site in its own OS process, and added Cross-Origin Read Blocking (CORB), now part of the Fetch spec. Modern defences layer the COOP, COEP, and CORP response headers on top of SOP to opt into full cross-origin isolation.

flowchart TD
  A[Script from https://app.example:443] --> B{Target origin matches?<br/>scheme + host + port}
  B -->|Same origin| C[Read response, DOM, cookies allowed]
  B -->|Cross origin| D{Explicit relaxation?}
  D -->|CORS / postMessage| E[Controlled, header-gated access]
  D -->|None| F[Browser blocks read<br/>CORB / opaque response]