Same-Origin Policy: Reads, Writes and CORS
By Ankit Jain · Updated
Learn what the browser isolates and why blocking response access does not prevent every cross-origin request.
The same-origin policy limits a script’s access to data and documents from other origins. It helps keep one website from reading another website’s private responses in your browser.
Reading and sending differ
A cross-origin image or form submission can be allowed without granting JavaScript access to a response body. A simple fetch request can also reach a server before the browser rejects response access. A preflighted request first needs the browser’s permission checks to succeed.
CORS provides controlled access to cross-origin HTTP responses. It does not generally grant access to another window’s DOM, make localStorage shared, or remove embedding restrictions imposed by other policies.
A practical example
https://app.example.com fetching /api/profile on the same origin normally does not need CORS. Fetching https://api.example.com/profile is cross-origin. The API must grant the page’s origin access if its response is to be readable.
Cookies are not simply isolated by origin: their rules include domain, path, Secure, and SameSite. Web storage such as localStorage uses origin boundaries. This distinction matters when two subdomains share cookie sessions.
What the policy does not guarantee
A server still needs authentication and authorization. Non-browser clients are not stopped by the browser’s policy. State-changing cookie requests still need CSRF protection. A blocked response does not undo a write that already reached your API.
For communication between windows, use a deliberately designed postMessage protocol with an exact target origin and validated incoming origin and data. CORS is not a replacement for that protocol.
Next: request types.