Same-Origin Policy (SOP)

The same-origin policy restricts how browser code from one origin can interact with resources from another origin. It is a core browser security boundary that helps prevent one website from freely reading sensitive data belonging to another site.

An origin is the combination of scheme, host, and port. Two URLs have the same origin only when all three components match; for example, `https://app.example.com` and `https://app.example.com:443` are typically the same origin because HTTPS uses port 443 by default, while a different subdomain is a different origin.

SOP primarily limits what JavaScript running in one origin can read or manipulate in another origin. It does not mean browsers block every cross-origin request: cross-origin navigation, embedding, and some network requests can be allowed, but the browser controls whether the initiating page can access the response or target resource.

For `fetch` and XMLHttpRequest, a cross-origin request generally requires the target server to opt into controlled read access through CORS response headers. The browser evaluates those headers; JavaScript cannot bypass SOP simply by setting a permissive request header on its own.

CORS is therefore an explicit mechanism layered on top of the browser's same-origin security model. A server can allow selected origins, methods, and headers, while credentials such as cookies require additional CORS rules and cannot be combined with an unrestricted wildcard origin.

SOP is enforced by the browser, not by the HTTP protocol itself. Server-to-server requests do not inherently have this browser-origin restriction, which is why a backend proxy can retrieve a resource without being subject to the browser's CORS enforcement in the same way.

Key points

• An origin is defined by scheme, host, and port.
• Different origins can communicate in limited ways, but browser JavaScript cannot freely read cross-origin data.
• CORS lets a server explicitly grant browser scripts cross-origin read access.
• SOP is a browser security policy, not an HTTP protocol rule.
• Credentials make cross-origin requests more restrictive and require appropriate CORS configuration.

Interview questions

What is the same-origin policy, and what exactly defines an origin?

The same-origin policy is a browser security mechanism that restricts how code from one origin can access resources from another origin. An origin consists of the scheme, host, and port. If any of those components differs, the origins are different. The browser then applies cross-origin access rules to operations such as DOM access and network response reading.

Does the same-origin policy prevent a frontend from making all cross-origin HTTP requests?

No. Browsers permit several kinds of cross-origin interaction, and a cross-origin request can sometimes be sent even when its response cannot be exposed to JavaScript. For APIs accessed through `fetch` or XMLHttpRequest, CORS response headers determine whether the browser allows the calling script to read the response. This distinction between sending a request and reading its response is important in frontend interviews.

How does CORS work with the same-origin policy?

CORS provides a controlled way for a server to tell the browser that a different origin may read a response. The server returns headers such as `Access-Control-Allow-Origin`, and the browser checks them before exposing the response to frontend JavaScript. For requests that require a preflight, the browser first sends an `OPTIONS` request describing the intended method and headers. The server must respond with an appropriate policy for the actual request to proceed.

Why doesn't adding `Access-Control-Allow-Origin` to a frontend request fix CORS?

`Access-Control-Allow-Origin` is a response header that the server uses to declare which origins may access the response. Adding it to a client request does not grant the browser permission to expose the response. The browser evaluates the server's CORS response, and for preflighted requests it also checks the server's response to the `OPTIONS` preflight. Therefore the API server or an intermediary under the application's control must provide the appropriate CORS policy.

What changes when a cross-origin request includes credentials?

Credentialed cross-origin requests can include browser credentials such as cookies when the request is configured appropriately. The server must explicitly permit credentials with `Access-Control-Allow-Credentials: true`, and the allowed origin must be explicit rather than an unrestricted `*` wildcard. CORS still does not replace authentication or authorization; it controls whether browser JavaScript can access the response. This distinction matters because a server can authenticate a request while still refusing to expose its response cross-origin.