The same-origin policy is often summarised as "a page cannot talk to another origin". In the browser, what does the same-origin policy actually prevent, and which cross-origin behaviours has it never prevented?

## What the policy is really guarding The same-origin policy exists because a browser runs code from many mutually distrusting parties in one process tree, holding credentials for all of them. Its job is to make sure that documents from origin A cannot *observe* anything belonging to origin B. Read that word carefully: the guarantee is about observation. It is narrower and stranger than "a page cannot talk to another origin", and most confusion about browser security comes from assuming the broader rule. ## The three families it blocks **Cross-document access.** If a page embeds an iframe from another origin, the parent may hold a reference to `iframe.contentWindow`, but reaching through it to `.document` throws a `SecurityError` DOMException. The same applies in reverse via `window.parent`, and to sibling frames. A small set of `Window` members stays reachable across origins by design — `postMessage`, `closed`, `length`, `frames`, `top`, `parent`, `opener`, `close`, `focus`, `blur`, and `location` as a *write* target — and that list is deliberately tiny and non-revealing. The rule shows up in less obvious places too: a stylesheet loaded from another origin appears in `document.styleSheets`, but reading its `cssRules` throws, because the rules could encode information the embedding page should not have. **Response contents.** A `fetch()` or `XMLHttpRequest` to another origin will not hand the response body, or most of its headers, to your script unless the responding server opts in with the appropriate response headers. In `no-cors` mode the request still goes out and you get an *opaque* response object — status 0, no readable body — which is useful only for handing to a cache or an `<img>`. **Storage and credentials.** `localStorage`, `sessionStorage` and IndexedDB are partitioned by origin; you can only ever see your own. Cookies are partitioned by host and path. There is no API to enumerate another origin's storage. ## What it never blocked The web was already full of cross-origin *composition* when the policy was written, and breaking that was never an option. So all of the following still work with no permission from anybody: - Embedding subresources: `<img src>`, `<script src>`, `<link rel=stylesheet>`, `<iframe>`, `<video>`, `<audio>`. (Web fonts are the odd one out — cross-origin `@font-face` files do require a CORS opt-in.) - Submitting a `<form>` to any origin, with any method. - Navigating the top-level window, or a frame you own, to any URL. - Sending a plain cross-origin `fetch` in `no-cors` mode. In every one of these cases the request leaves the browser, carries whatever cookies the cookie rules allow, and the destination server processes it normally. What the page does *not* get is the answer. A cross-origin `<script src>` is the extreme case: the response is not readable as data, yet it is executed with your origin's privileges — which is why you only include scripts from parties you trust as much as yourself, and why runtime errors from such a script are sanitized to the bare string `"Script error."` unless the tag carries `crossorigin` and the server sends matching headers. ## Why the asymmetry Once you see that requests go out but answers do not come back, two large facts about the web fall out. First, *the browser is not protecting your server*. Any page anywhere can cause a logged-in user's browser to issue a cookie-bearing POST to your endpoint. The attacker cannot read the response, but if the request alone changes state, the damage is done. State-changing endpoints therefore have to verify intent themselves; the origin policy will not do it for them. Second, side channels are the interesting attack surface. Because embedding is free, a page can often measure *whether* a cross-origin load succeeded, how long it took, or what dimensions an image had — small leaks that follow directly from "you may send and you may observe coarse outcomes, but you may not read". Browser hardening work over the last decade has largely been about narrowing those coarse observations. ## What this means in practice When a request fails in DevTools with a cross-origin message, check *which* half failed. If the network panel shows a real status code and the failure is in your JavaScript, the request succeeded and only the read was denied — the fix belongs on the server's response headers. If nothing hit the server at all, something stopped it before it left. And when you need two of your own origins to cooperate, the platform's supported channel is explicit messaging between the documents, not reaching through a frame reference.