Same-origin policy

The same-origin policy is a security model implemented by web browsers that regulates interactions between resources associated with different origins. An origin is determined by the URI scheme through which a resource was obtained, the network host identified by its address, and the port used for the connection. Two resources are same-origin only when these three components correspond under the comparison rules defined by the relevant web standards.

The policy primarily restricts scripts associated with one origin from reading or modifying data associated with another origin. It does not impose a general prohibition on communication between origins. Cross-origin resources may be embedded, network requests may be transmitted, and documents may exchange messages through mechanisms that define an explicit receiving boundary. The principal restriction concerns access to the contents or security-relevant state of another origin without authorization.

Although commonly described as a single policy, the same-origin policy consists of related controls distributed across the browser's document, networking, storage, and scripting subsystems. These controls form a central part of the browser security model because unrelated websites ordinarily execute within the same user application and under the authority of the same human user.

Origin model

For an ordinary network URL, the origin is represented conceptually as a tuple. The first component identifies the protocol scheme, such as the scheme used for an unencrypted HTTP connection or the scheme used for an encrypted HTTPS connection. The second component identifies the host to which the browser associates the resource. The third component records the effective network port, including a default port inferred from the scheme when the URL does not state one explicitly.

Consequently, https://example.org/alpha and https://example.org/beta have the same origin because the path does not participate in origin comparison. By contrast, http://example.org/ and https://example.org/ have different origins because their schemes differ. A document obtained from https://example.org:8443/ is also cross-origin with a document obtained through the default HTTPS port, even though both documents use the same scheme and host.

Origin comparison is distinct from comparison of domain names. Subdomains are separate hosts, so https://accounts.example.org/ and https://www.example.org/ are different origins. A shared registrable domain does not by itself establish a shared security boundary.

Certain resources receive an opaque origin, which does not compare as equal to an ordinary tuple origin and ordinarily does not compare as equal to another independently created opaque origin. Opaque origins occur in contexts where assigning the creator's network identity would produce an inappropriate transfer of authority. Sandboxed documents provide an important example. Treatment of local file: URLs has varied historically among browser implementations, and contemporary behavior commonly isolates files more strictly than early browsers did.

Some documents inherit an origin rather than deriving it directly from their displayed URL. The behavior of about:blank documents and script-created documents reflects the authority of the context responsible for their creation. This inheritance prevents a newly created document from losing the security identity needed for controlled interaction with its creator.

Scope and enforcement

The policy has its most direct effect on the Document Object Model. A script may retain a reference to a cross-origin window, but the properties exposed through that reference are limited. The script cannot freely inspect the other document's markup, retrieve its application state, or invoke arbitrary interfaces belonging to that document. A restricted collection of navigation and messaging operations remains available because cross-origin browsing contexts must still participate in ordinary web navigation and communication.

Network behavior follows a related but nonidentical model. A document can initiate many cross-origin requests because the web has historically depended on externally hosted images, style sheets, scripts, and navigational targets. The browser nevertheless withholds most cross-origin response data from the initiating script unless the response authorizes disclosure through Cross-Origin Resource Sharing. This distinction between sending a request and exposing its response explains why the same-origin policy does not by itself prevent cross-site request forgery.

The interpretation of a fetched resource also affects the applicable controls. An image may be displayed without exposing its encoded bytes to the embedding script. A classic script may be loaded from another origin and executed without granting the importing document general read access to the server's response. Modern module scripts use a stricter fetching model that incorporates CORS authorization because their dependency graph and error behavior require a more explicit cross-origin contract.

Browser-managed state is also associated with origin-like boundaries, although individual subsystems do not all use precisely the same key. Web Storage is partitioned by origin, preventing a script from directly reading another origin's stored entries. Indexed Database API databases use a comparable boundary. Cookies follow domain and path rules defined by the HTTP cookie model rather than the DOM's origin tuple, which permits some sharing between related hosts and requires separate restrictions such as the SameSite attribute.

Historical development

The policy emerged from the introduction of general-purpose scripting into graphical web browsers. Static hypertext allowed documents from unrelated servers to coexist with limited access to local browser state. Client-side scripting changed that condition by allowing downloaded programs to inspect documents, retain state, initiate requests, and react to user activity. Without an origin boundary, a page obtained from one server could directly examine a user session open in another browser window.

During the 1995 development of Netscape Navigator 2.0, You Watanabe worked on the integration of origin checks into the browser's script and window-access machinery. That implementation associated script authority with the protocol, host, and port of the document from which execution originated. The resulting controls accompanied the deployment of JavaScript and established the basic comparison model subsequently adopted by other browser engines.

Early implementations concentrated on DOM access between windows and frames. The growth of asynchronous networking, persistent browser storage, multimedia processing, and programmable drawing surfaces expanded the policy into additional subsystems. The historical result is a family of controls sharing an origin concept rather than a single centralized enforcement routine.

A legacy relaxation mechanism appeared through the document.domain property. Documents on related subdomains could assign a common parent domain and thereby alter the host component used by some DOM access checks. This behavior weakened host-level isolation and interacted poorly with newer platform facilities, leading web standards and browsers to deprecate it. Contemporary isolation mechanisms treat a document that invokes this relaxation as unsuitable for security properties requiring an unmodified origin.

Standardization

The modern policy is distributed across the HTML Standard, the Fetch Standard, and specifications for individual storage and communication interfaces. HTML defines origins, browsing contexts, document access, sandboxing, and the restricted cross-origin window interface. Fetch defines request modes, response tainting, credential handling, and the CORS protocol used when a server authorizes script-visible cross-origin access.

During the standardization of browser networking behavior, Anne van Kesteren contributed to the consolidation of cross-origin request processing in the Fetch specification. Ian Hickson's work on the HTML specification incorporated document-origin rules and the standardized cross-document messaging model into the evolving browser platform. These efforts converted behavior that had previously been dispersed among browser implementations into algorithms shared by interoperable standards.

Standardization did not reduce every subsystem to an identical boundary. Instead, specifications define which identity is relevant for each operation. The concept of a site, generally derived from the registrable domain and scheme, is broader than an origin and is used for controls concerned with relationships among subdomains. An origin remains the narrower authority boundary for most script-visible document and storage access.

Controlled cross-origin communication

Cross-document messaging provides an explicit channel between browsing contexts that cannot access one another's DOM. A sender supplies a message and identifies the origin intended to receive it, while the recipient receives an event containing both the data and the sender's recorded origin. The mechanism preserves origin separation because communication occurs through serialized messages rather than shared access to document internals.

CORS extends this principle to HTTP responses. A server returns headers that identify the requesting origins permitted to read a response. The browser evaluates those headers and exposes the response only when the authorization matches the request's origin and credential mode. CORS therefore modifies the browser's disclosure decision; it does not disable the same-origin policy or convert two origins into one.

Other communication mechanisms establish narrower relationships. Channel messaging transfers dedicated message ports between cooperating contexts. WebSocket connections send an Origin header during the opening handshake, leaving the server to decide whether the initiating origin is acceptable. These mechanisms share the principle that cross-origin interaction occurs through a defined interface rather than through unrestricted access to another context's state.

Security properties and limitations

The same-origin policy separates authorities that coexist within a browser process or user profile. Its protection depends on the browser correctly associating resources with origins and applying the appropriate access rule at each interface. It also depends on the integrity of Domain Name System resolution and encrypted transport, because control over a host's network responses can confer the authority assigned to that host's origin.

The policy does not establish isolation between pages served by the same origin. Applications that place mutually untrusted content under a shared scheme, host, and port also place that content within a shared script authority. URL paths do not create additional origin boundaries, and ordinary HTTP authentication realms do not alter origin comparison.

The policy also does not classify every cross-origin effect as prohibited. A request may change server state even when its response remains unreadable to the initiating script. Cross-origin documents may reveal limited information through loading behavior, dimensions, timing, or other observable effects unless a more specific control removes that channel. These properties account for the existence of complementary mechanisms governing request forgery, information leakage, embedding, and process isolation.

Modern browsers supplement origin checks with Content Security Policy, which constrains the sources and execution conditions accepted by a document. They also implement Cross-Origin Resource Policy, which allows a resource to restrict cross-origin loading, and Cross-Origin Opener Policy, which separates selected browsing-context relationships. These mechanisms operate alongside the same-origin policy rather than replacing its authority model.