Same-Origin Policy

Why It Matters

Without it, any page you opened could quietly read your webmail in another tab. That is the whole point, and it is why the policy is not configurable by users or by sites. The practical consequence for anyone publishing files is that origin boundaries are also data boundaries. Move a page from one subdomain to another and its localStorage does not follow, because storage is keyed by origin — a saved draft, a theme setting, a list of entries all appear to vanish. Two pages that need to share state must sit on the same origin or exchange messages deliberately with postMessage.

How It Works

The browser tags every document with its origin and checks that tag on each access. A cross-origin fetch is still sent, but the response body is withheld from the calling script unless Access-Control-Allow-Origin names the caller; this is exactly the hole CORS was designed to open in a controlled way. Frames are similar: a parent can set the src of a cross-origin iframe and can post messages into it with window.postMessage, but cannot read its DOM. Cookies follow a looser, older rule based on domain and path rather than full origin, which is why SameSite attributes exist as a separate control. Where two documents share a parent domain, both can set document.domain to that parent to relax the check — a legacy mechanism now deprecated and disabled by default in current browsers.

Real-World Example

Common Mistakes

• ✕Thinking the policy blocks requests — it blocks the script from reading the reply, while the request itself usually still reaches the server
• ✕Expecting localStorage to follow a page across subdomains — storage is per origin, so moving the page loses the data
• ✕Counting http and https versions of a host as one origin — the scheme is part of the origin, so they are separate
• ✕Reaching for document.domain to bridge two subdomains, a deprecated mechanism that modern browsers ignore

Related Terms