Last updated: Sep 9, 2026

Same-Origin Policy

The Same-Origin Policy (SOP) is a browser rule that treats documents from different origins as untrusted to each other. An origin is the protocol + host + port (https, app.example.com, 443). SOP blocks most reads of another origin’s data, it does not block every cross-origin write. Only the browser enforces this.

What SOP allows and blocks

A page may not read another origin’s response body, DOM, or cookies. That is the core rule. How a request is sent depends on how it was made.

CORS does not turn SOP off. It is only the server’s opt-in so JavaScript may read that HTTP response. Another origin’s DOM and cookies stay blocked.

Forms and embeds do not use CORS. The browser still sends them:

• Form GET / POST to another origin (the page navigates; JavaScript does not get the response as data)
• <script>, <img>, <iframe>, <link>, <video> from another origin
• Cookies on those requests, when cookie attributes allow it

That gap — a write that still happens, with no readable response — is why CSRF exists.

fetch and XHR do use CORS. A simple request (CORS-safelisted GET/HEAD/POST) is sent even when the server sends no CORS headers; JavaScript just cannot read the result. Anything else is preflighted: the browser sends OPTIONS first, and the real request goes out only if that response allows it.

Talking across origins

These are the usual ways pages still work with another origin. They are not a single “bypass SOP” switch.