The Web Origin Concept
Extracted elements (22)
An origin is defined as the triple (scheme, host, port) rather than just the host because including the scheme is essential for security: without it, there would be no isolation between http://example.com and https://example.com, allowing an active network attacker to corrupt HTTP content and compromise HTTPS content, bypassing TLS protections.
Privileges should be granted or withheld from origins as a whole rather than from individual resources within an origin, because user agents do not isolate resources within an origin and a resource without a privilege can usually obtain it from another resource in the same origin.
The fully qualified host name is used instead of just the top-level domain because trust relationships between host names vary by deployment. For example, at educational institutions, student-hosted content and grade management applications share the same top-level domain but must be isolated from each other.
URI is not necessarily same-origin with itself: for example, a data URI is not same-origin with itself because data URIs do not use a server-based naming authority and therefore have globally unique identifiers as origins, meaning the algorithm may produce different values on repeated invocations.
User agents determine how much authority to grant a resource by examining its media type: passive content such as images carries no authority, while active content such as HTML documents carries the full authority of its origin. Content sniffing that misidentifies media types can lead to privilege escalation vulnerabilities.
This document assumes user agents perform IDNA processing and validation when constructing URIs, such that uri-host contains only LDH labels (non-ASCII labels converted to A-labels). Origin-based security policies are therefore sensitive to the specific IDNA algorithm employed.
Each serialized-origin in a generated Origin header field MUST be the ASCII serialization of an origin. No two consecutive serialized-origin productions may be identical; if the user agent would generate two consecutive identical ones, it MUST NOT generate the second.
For 'file' URIs, the implementation MAY return an implementation-defined value as the origin. Historically, user agents have granted file scheme content wide privileges, but granting all local files such privileges can lead to privilege escalation attacks.
The user agent MUST NOT include more than one Origin header field in any HTTP request.
Using 'registry-controlled' domains (e.g., 'example.com' instead of 'www.example.com') as the unit of isolation is NOT RECOMMENDED because the notion of a registry-controlled domain depends on human practice rather than DNS properties, and is incompatible with non-DNS URI schemes.
Whenever a user agent issues an HTTP request from a 'privacy-sensitive' context, it MUST send the value 'null' in the Origin header field.
An origin is either a scheme/host/port triple (for hierarchical URIs with a supported scheme) or a globally unique identifier (for URIs without a server-based naming authority, unsupported schemes, or when the algorithm generates a fresh value). Two origins are the same if and only if they are identical.
The ASCII serialization of an origin returns the string 'null' for non-scheme/host/port origins, or constructs 'scheme://host[:port]' using the raw host component and omitting the port if it equals the scheme's default port.
The Origin header field, when included in an HTTP request, indicates the origin(s) that caused the user agent to issue the request, as defined by the API that triggered the request. Multiple origins may be listed if multiple origins contributed to causing the request (e.g., through redirects).
The origin of a URI is computed by: extracting the scheme (lowercased), host (lowercased), and port (defaulting to the scheme's default if absent), returning a scheme/host/port triple; or returning a fresh globally unique identifier for non-hierarchical URIs, unsupported schemes, or 'file' URIs.
The Unicode serialization of an origin returns the string 'null' for non-scheme/host/port origins, or constructs 'scheme://host[:port]' where A-labels in the host are converted to corresponding U-labels, and the port is omitted if it equals the default for the scheme.
The permanent message header field registry (RFC 3864) has been updated to register the 'Origin' header field with applicable protocol 'http', status 'standard', and IETF as the change controller.
Many older technologies (e.g., cookies) predate the web origin concept and use different isolation units, leading to vulnerabilities. Using registry-controlled domains as the isolation unit is problematic due to inconsistent public suffix lists and incompatibility with non-DNS URI schemes.
The same-origin policy grants authority based on URI rather than on which objects the content can designate, an example of ambient authority. This enables cross-site scripting: injected scripts run with the document origin's authority, potentially accessing sensitive resources.
The same-origin policy relies on DNS for security because many URI schemes use DNS-based naming authorities. If DNS is compromised, the same-origin policy may fail to provide required security properties. HTTPS URIs are more resistant due to certificate-based verification.
The security properties of the same-origin policy depend on the IDNA algorithm employed by the user agent. Migrating between IDNA2003 and IDNA2008 may redraw security boundaries, potentially combining two mutually distrusting entities into the same origin.
The Origin HTTP header field has the syntax: 'Origin: OWS origin-list-or-null OWS', where origin-list-or-null is either the literal string 'null' or a space-separated list of serialized-origin values, each of the form 'scheme://host[:port]'.