Same-Origin Policy

Updated September 30, 20262 min read

In short

The same-origin policy is a browser security rule that stops scripts on one website from reading data from another site unless that site explicitly allows it.

What is the same-origin policy?

The same-origin policy is the browser's basic isolation rule. It lets a web page freely interact with resources from its own origin, but it blocks the page's scripts from reading responses, pages, or storage that belong to other origins. Without it, any website you visit could use your browser, and your cookies, to read your email or your bank balance from other sites.

An origin is the combination of scheme, host, and port, as in https://app.example.com:443. Two URLs have the same origin only if all three match, so http://example.com and https://example.com are different origins, and so are example.com and api.example.com. The policy mostly restricts reading, not sending: a page can still embed images, scripts, and iframes from other origins and submit forms to them, but its JavaScript cannot read a cross-origin fetch response, the DOM of a cross-origin iframe, or another origin's cookies and local storage.

It is like the mailboxes in an apartment lobby: anyone can drop a letter into any box, but only the resident with the key can open a box and read what is inside. Controlled ways to relax the rule exist, such as CORS for cross-origin fetch requests and postMessage for communication between windows and iframes. The focus on reading also explains why other defenses are still needed: cross-site requests can still be sent, so CSRF remains possible, and framing is allowed by default, so clickjacking needs its own protection.

The same-origin policy is often confused with CORS. The same-origin policy is the default restriction built into browsers, while CORS is a mechanism that lets a server loosen it by sending headers such as Access-Control-Allow-Origin, so a CORS error means the policy is working as designed. Both are enforced only by browsers, which means they don't protect an API from scripts or servers that call it directly.

Key takeaways

The same-origin policy stops scripts on one origin from reading data from another.
An origin is the scheme, host, and port together.
Cross-origin sending and embedding are mostly allowed; reading the results is blocked.
CORS and postMessage are the standard, controlled ways to relax the policy.
It is enforced by browsers and is not a replacement for server-side authorization.

Example

Which requests count as cross-originjavascript

// This page runs on https://shop.example.com
await fetch("/api/cart"); // same origin: allowed

// A different host is a different origin: reading the response is blocked
// unless api.other.com replies with a matching CORS header
await fetch("https://api.other.com/data");

// All of these are different origins from https://shop.example.com:
// http://shop.example.com        (different scheme)
// https://www.example.com        (different host)
// https://shop.example.com:8443  (different port)

Readers ask

What counts as the same origin?

Two URLs share an origin when their scheme, host, and port are all identical. https://example.com/a and https://example.com/b are the same origin, while https://example.com and https://api.example.com are not.

What is the difference between the same-origin policy and CORS?

The same-origin policy is the browser's default rule that blocks scripts from reading cross-origin responses. CORS is an opt-in mechanism a server uses to allow specific other origins to read its responses.

Does the same-origin policy prevent CSRF?

No. It stops the attacker's page from reading the response, but the browser still sends the cross-site request, often with the user's cookies. CSRF protection needs tokens, SameSite cookies, or origin checks on the server.