Same-Origin Policy

web security

Definition

Same-Origin Policy (SOP)

The Same-Origin Policy is the baseline access-control policy implemented by browsers (introduced by Netscape 2 in 1995). A script running on an origin may access only resources from the same origin:

• read/write access to the DOM,
• read/write access to the cookie jar (under a relaxed notion of site),
• read access to a network response body.

So a user visiting evil.com in one tab and bank.com in another cannot have evil.com’s script touch the bank account. The same restriction applies to iframes and other embedded contexts.

Cross-Origin Requests

Observation

The SOP does not forbid cross-origin requests — a form on evil.com can still POST to bank.com. It only forbids reading the response or the target’s DOM. Cross-origin reads are relaxed in a controlled way by CORS and by postMessage.

Example

Two tabs, three origins

A user has https://www.example.com open in one tab and https://www.example.com:8443 in another, while an attacker’s page at https://evil.com runs in a third. Three origins are in play:

Page	Origin	Can read www.example.com’s DOM?
https://www.example.com	<https, www.example.com, 443>	yes (same origin)
https://www.example.com:8443	<https, www.example.com, 8443>	no — different port
https://evil.com	<https, evil.com, 443>	no — different host

A change of scheme, host, or port each suffices to make the origin different. So a script on https://evil.com gets nothing from bank.com: no DOM read, no cookie-jar read, no peeking at the response body of a fetch('https://bank.com'). The bank tab and the attacker tab share no origin, and the SOP draws the line there.