The Same-Origin Policy and the Security Boundary of the Web Browser
The same-origin policy became the browser's core isolation rule, letting users visit mutually untrusted sites while restricting one site's scripts from reading another site's private state.
JavaScript made the browser a place where mutually suspicious programs had to coexist
Early web pages were mostly documents, but JavaScript changed the browser into an execution environment. Once scripts could inspect documents, open windows and manipulate page state, a serious problem appeared: a script delivered by one website might run while the user was simultaneously authenticated to another. Mozilla’s historical documentation says the same-origin policy dates to Netscape Navigator 2.0, the era in which JavaScript entered mainstream browsers.[1] The browser therefore needed an isolation rule that let scripts be useful without giving every visited site equal authority over every other site.
The threat came from ambient user authority
A malicious page could potentially exploit the browser’s existing cookies, network access and authenticated sessions unless the browser distinguished one site’s authority from another’s.
An origin became the browser’s unit of security identity
Modern browsers generally define an origin using the scheme, host and port associated with a resource. MDN explains that two URLs are same-origin only when those components match.[2] Its origin glossary likewise defines the origin as the scheme, hostname and port tuple and notes the role of opaque origins for contexts that should not inherit ordinary authority.[5] Paths do not create separate origins, while changing from HTTP to HTTPS, changing the hostname or changing the port can. This tuple became a compact answer to a difficult question: which documents should be allowed to treat one another as mutually trusted?
The policy restricts reading across origins more strongly than linking across them
The Web could not function if sites were forbidden to reference one another. Images, links, forms and scripts have long crossed site boundaries. The same-origin policy is therefore not a complete ban on cross-origin interaction. It primarily restricts sensitive reads and direct scripting access. MDN describes the policy as preventing a potentially malicious document from reading data from a third-party webmail service or intranet that the user can access.[2] The W3C security wiki similarly explains that distinct origins are generally isolated even though some cross-origin network actions remain possible.[3]
Sending and reading are different security operations
A browser may allow a page to cause a request to another site while refusing to reveal the response to the requesting script.
The Document Object Model made same-origin checks especially important
Frames and popup windows meant multiple documents could exist inside one browser context. Without isolation, a script in an advertising frame or malicious tab could inspect account pages, extract personal information or modify another site’s interface. Mozilla’s archived same-origin documentation describes restrictions on getting or setting properties of a document from a different origin and records the old document.domain relaxation mechanism.[1] That mechanism was later deprecated because weakening origin boundaries created complexity and security risk.
The origin model expanded beyond documents to storage and application state
As browsers acquired cookies, Web Storage, IndexedDB, workers and other capabilities, origin isolation became more than a DOM rule. MDN notes that data stores such as Web Storage and IndexedDB are separated by origin.[2] The modern HTML standard calls origins the “fundamental currency” of the web’s security model and treats actors with different origins as potentially hostile.[4] This language captures how central the abstraction became: browser security decisions across many APIs now begin by asking which origin owns the action or data.
Origin is a security principal implemented by the browser
Applications rely on the browser to attach network, storage and scripting privileges to this principal consistently across APIs.
CORS created a controlled way to relax cross-origin reading
Modern web applications often need APIs hosted on different domains, so rigid same-origin isolation would block legitimate architectures. Cross-Origin Resource Sharing allows servers to declare which origins may read certain responses. The crucial shift is that the target server participates in the decision. The default remains isolation, while an explicit response header can grant a defined exception.[2] CORS therefore does not abolish the same-origin policy; it provides a standardized permission mechanism around it.
The policy is powerful because it assumes websites are mutually untrusted by default
The browser routinely executes code from organizations that have no relationship with one another. The same-origin policy makes that possible by rejecting the assumption that all pages open in one browser should share authority. The W3C’s description emphasizes the goal of allowing users to visit untrusted sites without those sites interfering with sessions at honest sites.[3] Modern HTML formalizes origins and opaque origins to support increasingly complex navigation, sandboxing and embedded-content cases.[4]
The browser is effectively a multi-tenant runtime
Isolation is what lets banking, social media, documentation and an unknown website coexist inside one process tree without intentionally sharing all of their data.
Why the same-origin policy belongs in the history of computer security
The same-origin policy belongs in security history because it created a default boundary for executable content on the open Web. It emerged with early JavaScript, evolved into the scheme-host-port origin model, and expanded from DOM access into storage and platform-wide authority.[1][2][4]
The rule is imperfect and full of carefully designed exceptions, but that complexity reflects the Web’s unusual architecture. Browsers must support cross-site linking and composition while protecting sessions, data and scripting state from mutually untrusted origins.
Its historical significance is therefore larger than one browser feature. Same-origin policy is an example of security by compartmentalization: assume code from different sources may be hostile, then give each a bounded domain of authority. Much of modern web security is built on refinements of that original isolation decision.
Works Cited
- 01Mozilla Archive — JavaScript Security: Same Origin www-archive.mozilla.org
- 02MDN — Same-Origin Policy developer.mozilla.org
- 03
- 04WHATWG — HTML Living Standard: Origins html.spec.whatwg.org
- 05MDN — Origin Glossary developer.mozilla.org
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.
Submit a research lead