How Does the Same-Origin Policy Protect a Browser?

Same-Origin Policy Explainer

The same-origin policy is a foundational browser rule that separates content loaded from different web origins. Without it, a malicious page opened in one tab could use a visitor’s logged-in browser state to read private mail, bank balances, internal dashboards, or another site’s page data. The policy does not isolate every network action, but it restricts a script’s ability to inspect and manipulate resources that belong to a different origin. It creates the default boundary on which many other web security features depend.

An origin is primarily the combination of scheme, host, and port. `https://example.com` and `https://example.com:443` normally share an origin because 443 is the default HTTPS port. Changing from HTTPS to HTTP, changing the host, or using a different nondefault port creates another origin. Paths do not matter: two pages under different directories on the same origin can usually interact. Similar-looking domain names are not enough, and a subdomain is normally distinct from its parent or sibling.

For documents, the policy limits access to the Document Object Model and many JavaScript objects. A script in one origin cannot freely read another origin’s page content, cookies, storage, or frame details. A small set of cross-origin window operations is permitted so pages can navigate or communicate in controlled ways. Documents that intentionally cooperate can use `postMessage`, which sends explicit data to a specified origin. The receiving page must verify the sender and validate the message rather than treating cross-origin input as trusted.

Cross-origin resource use is more nuanced than a total network block. Pages have long been able to embed images, style sheets, frames, and scripts from other sites under category-specific rules. Forms can send cross-origin requests, and some network requests may be transmitted even when the calling script cannot read the response. This distinction helps explain cross-site request forgery: preventing response access does not always prevent a browser from sending an authenticated action. Cookies therefore need attributes and servers need request-forgery defenses in addition to relying on the same-origin policy.

When a site wants to let another origin read a response, Cross-Origin Resource Sharing provides an explicit HTTP-based permission system. Other mechanisms narrow particular capabilities: iframe sandboxing removes privileges, Content Security Policy limits loading and execution, and cross-origin isolation headers create stronger conditions for sensitive APIs. These mechanisms build on the origin concept but solve different problems. Relaxing one control does not erase every boundary, and a permission should be granted only to the origins and methods that actually need it.

The origin boundary is powerful, not perfect. Vulnerable code served from an origin inherits that origin’s authority, so cross-site scripting can operate as the compromised site. DNS or hosting mistakes can also put untrusted applications under a trusted origin. Browser extensions and downloaded files follow additional rules, and legacy attempts to weaken origin separation can create surprising access. Modern applications should keep unrelated trust zones on distinct origins, avoid serving user-controlled active content beside sensitive pages, validate `postMessage` traffic, and combine origin isolation with CSRF and injection defenses. The same-origin policy’s enduring role is to make isolation the default: websites may link to and use one another, but they do not automatically gain permission to read or control one another’s protected state.

Storage follows the same trust model. Local storage, indexed databases, and many caches are partitioned or keyed with origin information so unrelated sites cannot simply enumerate one another’s data. Cookie scope uses domain and path rules rather than being identical to the origin definition, which is why secure attributes and careful subdomain ownership remain important. Newer browser privacy protections may partition more state by the top-level site as well. Developers should avoid assuming that every feature uses precisely one boundary; they should consult the feature’s rules while treating origin separation as the baseline for script authority.