The Same-Origin Policy: what an origin is and what it isolates

What it is

RFC 6454 defines an origin as the tuple of scheme, host and port; MDN calls it the "scheme/host/port tuple". https://example.com, https://example.com:8443, http://example.com and https://app.example.com are four different origins; path and query play no part. The same-origin policy is the browser's rule for interactions between origins. MDN sorts them into three groups: cross-origin writes (links, redirects, form submissions) are typically allowed; cross-origin embedding (img, script, iframe, stylesheets, fonts) is typically allowed, but the embedded content is opaque to script; cross-origin reads (the DOM of another window or frame, the body of a fetch response, another origin's storage) are typically disallowed. CORS is the server-side opt-in that relaxes reads. Cookies follow their own scope: RFC 6265 notes that they do not provide isolation by port.

Why it matters

The policy is why a hostile page cannot load your bank in a hidden frame and read the balance, and also why a legitimate front-end on another origin cannot read your API's responses until the API says so. Two classes of mistake follow from misunderstanding it: opening CORS to every origin with credentials because "the browser blocked it", and assuming the policy prevents cross-site request forgery, which it does not, because writes are allowed.

How to apply

• Prefer one origin for application and API (a reverse proxy under one host); it removes CORS configuration and keeps cookies simple.
• Treat subdomains as foreign for script and storage; a cookie with Domain=example.com spans them, which matters when one subdomain hosts user content.
• Never use document.domain to loosen the check; MDN marks it deprecated because it undermines the isolation.
• Exchange data with embedded third-party frames through postMessage with an explicit target origin, and verify event.origin on receipt.
• Protect state-changing endpoints with CSRF tokens or SameSite cookies; the policy will not.
• Control who may frame you with the CSP frame-ancestors directive, and who may load your subresources with Cross-Origin-Resource-Policy.

Pitfalls

During development http://localhost:3000 and http://localhost:5173 are distinct origins, which is why dev servers offer proxies. An iframe of another origin cannot be inspected by the parent, but the parent can navigate it. A response fetched with mode: "no-cors" is opaque: the page that requested it can read neither its status nor its body.