What Is the Same-Origin Policy?

The same-origin policy is the browser rule that stops JavaScript on one website from reading data that belongs to another. An origin is the exact combination of scheme, host, and port; if any of the three differ, the browser treats the two contexts as strangers. It is the foundation the rest of web security is built on.

Why does the web need a same-origin policy?#

Your browser is one process holding sessions for your bank, your email, and a tab of random links. Without an isolation rule, any page could quietly fire a request to your bank — riding on your logged-in cookies — and read the response. The same-origin policy is what makes having twenty tabs open survivable: pages can request a lot, but they can only read what their own origin owns.

That distinction — sending versus reading — explains most of the confusing edge cases. A page can embed an image from anywhere, submit a form to anywhere, even send a fetch() to anywhere. What it cannot do, by default, is read the bytes that come back from a different origin.

What exactly counts as an origin?#

An origin is the tuple scheme + host + port, compared character-for-character. There is no “close enough”:

URL A	URL B	Same origin?	Why
https://example.com/a	https://example.com/b/c	Yes	Path is ignored
https://example.com	http://example.com	No	Scheme differs
https://example.com	https://app.example.com	No	Host differs
https://example.com	https://example.com:8443	No	Port differs
https://example.com:443	https://example.com	Yes	443 is the HTTPS default

What does the policy actually block?#

The same-origin policy governs read access between browsing contexts and responses. In practice, cross-origin JavaScript cannot:

1. Read the DOM of a window or iframe from another origin.
2. Read the response body of a fetch()/XMLHttpRequest to another origin (unless CORS allows it).
3. Read another origin’s cookies, localStorage, or IndexedDB.

What it deliberately does not block: embedding cross-origin images, styles, and scripts; navigating to other origins; and submitting forms cross-origin. The web’s openness and its biggest quirks both live in that gap — cross-site request forgery exists precisely because sending was left open.

How does CORS relax the policy safely?#

Cross-Origin Resource Sharing is the server’s way of saying “these specific strangers may read me.” The server — the owner of the data — opts in via response headers:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Credentials: true
Vary: Origin

The browser enforces the contract: if the requesting origin is not on the list, the response is fetched but never handed to the page’s JavaScript. Two rules keep CORS deployments safe:

1. Never reflect the request’s Origin header back blindly — that is equivalent to * with credentials.
2. Treat Access-Control-Allow-Credentials: true as a loaded weapon; combine it only with an exact-match allowlist.

Where does the same-origin policy fail you?#

The policy protects origins from each other. It cannot protect an origin from itself. If an attacker gets script injected into your page — the attack class covered in our cross-site scripting deep dive — that script is same-origin, and SOP grants it everything. This is why defense in depth pairs SOP with output encoding, a Content Security Policy, and the security headers that harden the browser’s defaults.

For the full context of where this rule sits in the web security stack, start at the Web Security hub.