💥 TRENDING: Multipage/browsers.html - High Quality

  1. 7 Loading web pages
    1. 7.1 Supporting concepts
      1. 7.1.1 Origins
        1. 7.1.1.1 Sites
        2. 7.1.1.2 Relaxing the same-origin restriction
        3. 7.1.1.3 The Origin interface
      2. 7.1.2 Origin-keyed agent clusters
      3. 7.1.3 Cross-origin opener policies
        1. 7.1.3.1 The headers
        2. 7.1.3.2 Browsing context group switches due to opener policy
        3. 7.1.3.3 Reporting
      4. 7.1.4 Cross-origin embedder policies
        1. 7.1.4.1 The headers
        2. 7.1.4.2 Embedder policy checks
      5. 7.1.5 Sandboxing
      6. 7.1.6 Policy containers

7 Loading web pages

This section describes features that apply most directly to web browsers. Having said that, except where specified otherwise, the requirements defined in this section do apply to all user agents, whether they are web browsers or not.

7.1 Supporting concepts

7.1.1 Origins

Origins are the fundamental currency of the web's security model. Two actors in the web platform that share an origin are assumed to trust each other and to have the same authority. Actors with differing origins are considered potentially hostile versus each other, and are isolated from each other to varying degrees.

For example, if Example Bank's web site, hosted at bank.example.com, tries to examine the DOM of Example Charity's web site, hosted at charity.example.org, a "SecurityError" DOMException will be raised.

An origin is one of the following:

An opaque origin

An internal value, with no serialization it can be recreated from (it is serialized as "null" per serialization of an origin), for which the only meaningful operation is testing for equality.

A tuple origin

A tuple consisting of:

  • A scheme (an ASCII string).
  • A host (a host).
  • A port (null or a 16-bit unsigned integer).
  • A domain (null or a domain). Null unless stated otherwise.

Origins can be shared, e.g., among multiple Document objects. Furthermore, origins are generally immutable. Only the domain of a tuple origin can be changed, and only through the document.domain API.

The effective domain of an origin origin is computed as follows:

  1. If origin is an opaque origin, then return null.

  2. If origin's domain is non-null, then return origin's domain.

  3. Return origin's host.

The serialization of an origin is the string obtained by applying the following algorithm to the given origin origin:

  1. If origin is an opaque origin, then return "null".

  2. Otherwise, let result be origin's scheme.

  3. Append "://" to result.

  4. Append origin's host, serialized, to result.

  5. If origin's port is non-null, append a U+003A COLON character (:), and origin's port, serialized, to result.

  6. Return result.

The serialization of ("https", "xn--maraa-rta.example", null, null) is "https://xn--maraa-rta.example".

There used to also be a Unicode serialization of an origin. However, it was never widely adopted.

Two origins, A and B, are said to be same origin if the following algorithm returns true:

  1. If A and B are the same opaque origin, then return true.

  2. If A and B are both tuple origins and their schemes, hosts, and port are identical, then return true.

  3. Return false.

Two origins, A and B, are said to be same origin-domain if the following algorithm returns true:

  1. If A and B are the same opaque origin, then return true.

  2. If A and B are both tuple origins:

    1. If A and B's schemes are identical, and their domains are identical and non-null, then return true.

    2. Otherwise, if A and B are same origin and their domains are both null, return true.

  3. Return false.

A B same origin same origin-domain
("https", "example.org", null, null) ("https", "example.org", null, null) ✅ ✅
("https", "example.org", 314, null) ("https", "example.org", 420, null) ❌ ❌
("https", "example.org", 314, "example.org") ("https", "example.org", 420, "example.org") ❌ ✅
("https", "example.org", null, null) ("https", "example.org", null, "example.org") ✅ ❌
("https", "example.org", null, "example.org") ("http", "example.org", null, "example.org") ❌ ❌
7.1.1.1 Sites

A scheme-and-host is a tuple of a scheme (an ASCII string) and a host (a host).

A site is an opaque origin or a scheme-and-host.

To obtain a site, given an origin origin, run these steps:

  1. If origin is an opaque origin, then return origin.

  2. If origin's host's registrable domain is null, then return (origin's scheme, origin's host).

  3. Return (origin's scheme, origin's host's registrable domain).

Two sites, A and B, are said to be same site if the following algorithm returns true:

  1. If A and B are the same opaque origin, then return true.

  2. If A or B is an opaque origin, then return false.

  3. If A's and B's scheme values are different, then return false.

  4. If A's and B's host values are not equal, then return false.

  5. Return true.

The serialization of a site is the string obtained by applying the following algorithm to the given site site:

  1. If site is an opaque origin, then return "null".

  2. Let result be site[0].

  3. Append "://" to result.

  4. Append site[1], serialized, to result.

  5. Return result.

It needs to be clear from context that the serialized value is a site, not an origin, as there is not necessarily a syntactic difference between the two. For example, the origin ("https", "shop.example", null, null) and the site ("https", "shop.example") have the same serialization: "https://shop.example".

Two origins, A and B, are said to be schemelessly same site if the following algorithm returns true:

  1. If A and B are the same opaque origin, then return true.

  2. If A and B are both tuple origins, then:

    1. Let hostA be A's host, and let hostB be B's host.

    2. If hostA equals hostB and hostA's registrable domain is null, then return true.

    3. If hostA's registrable domain equals hostB's registrable domain and is non-null, then return true.

  3. Return false.

Two origins, A and B, are said to be same site if the following algorithm returns true:

  1. Let siteA be the result of obtaining a site given A.

  2. Let siteB be the result of obtaining a site given B.

  3. If siteA is same site with siteB, then return true.

  4. Return false.

Unlike the same origin and same origin-domain concepts, for schemelessly same site and same site, the port and domain components are ignored.

For the reasons explained in URL, the same site and schemelessly same site concepts should be avoided when possible, in favor of same origin checks.

Given that wildlife.museum, museum, and com are public suffixes and that example.com is not:

A B schemelessly same site same site
("https", "example.com") ("https", "sub.example.com") ✅ ✅
("https", "example.com") ("https", "sub.other.example.com") ✅ ✅
("https", "example.com") ("http", "non-secure.example.com") ✅ ❌
("https", "r.wildlife.museum") ("https", "sub.r.wildlife.museum") ✅ ✅
("https", "r.wildlife.museum") ("https", "sub.other.r.wildlife.museum") ✅ ✅
("https", "r.wildlife.museum") ("https", "other.wildlife.museum") ❌ ❌
("https", "r.wildlife.museum") ("https", "wildlife.museum") ❌ ❌
("https", "wildlife.museum") ("https", "wildlife.museum") ✅ ✅
("https", "example.com") ("https", "example.com.") ❌ ❌

(Here we have omitted the port and domain components since they are not considered.)

7.1.1.2 Relaxing the same-origin restriction
document.domain [ = domain ]

Returns the current domain used for security checks.

Can be set to a value that removes subdomains, to change the origin's domain to allow pages on other subdomains of the same domain (if they do the same thing) to access each other. This enables pages on different hosts of a domain to synchronously access each other's DOMs.

In sandboxed iframes, Documents with opaque origins, and Documents without a browsing context, the setter will throw a "SecurityError" exception. In cases where crossOriginIsolated or originAgentCluster return true, the setter will do nothing.

Avoid using the document.domain setter. It undermines the security protections provided by the same-origin policy. This is especially acute when using shared hosting; for example, if an untrusted third party is able to host an HTTP server at the same IP address but on a different port, then the same-origin protection that normally protects two different sites on the same host will fail, as the ports are ignored when comparing origins after the document.domain setter has been used.

Because of these security pitfalls, this feature is in the process of being removed from the web platform. (This is a long process that takes many years.)

Instead, use postMessage() or MessageChannel objects to communicate across origins in a safe manner.

The domain getter steps are:

  1. Let effectiveDomain be this's origin's effective domain.

  2. If effectiveDomain is null, then return the empty string.

  3. Return effectiveDomain, serialized.

The domain setter steps are:

  1. If this's browsing context is null, then throw a "SecurityError" DOMException.

  2. If this's active sandboxing flag set has its sandboxed document.domain browsing context flag set, then throw a "SecurityError" DOMException.

  3. Let effectiveDomain be this's origin's effective domain.

  4. If effectiveDomain is null, then throw a "SecurityError" DOMException.

  5. If the given value is not a registrable domain suffix of and is not equal to effectiveDomain, then throw a "SecurityError" DOMException.

  6. If the surrounding agent's agent cluster's is origin-keyed is true, then return.

  7. Set this's origin's domain to the result of parsing the given value.

To determine if a scalar value string hostSuffixString is a registrable domain suffix of or is equal to a host originalHost:

  1. If hostSuffixString is the empty string, then return false.

  2. Let hostSuffix be the result of parsing hostSuffixString.

  3. If hostSuffix is failure, then return false.

  4. If hostSuffix does not equal originalHost, then:

    1. If hostSuffix or originalHost is not a domain, then return false.

      This excludes hosts that are IP addresses.

    2. If hostSuffix, prefixed by U+002E (.), does not match the end of originalHost, then return false.

    3. If any of the following are true:

      then return false. [URL]

    4. Assert: originalHost's public suffix, prefixed by U+002E (.), matches the end of hostSuffix.

  5. Return true.

hostSuffixStringoriginalHostOutcome of is a registrable domain suffix of or is equal toNotes
"0.0.0.0"0.0.0.0✅
"0x10203"0.1.2.3✅
"[0::1]"::1✅
"example.com"example.com✅
"example.com"example.com.❌Trailing dot is significant.
"example.com."example.com❌
"example.com"www.example.com✅
"com"example.com❌At the time of writing, com is a public suffix.
"example"example✅
"compute.amazonaws.com"example.compute.amazonaws.com❌At the time of writing, *.compute.amazonaws.com is a public suffix.
"example.compute.amazonaws.com"www.example.compute.amazonaws.com❌
"amazonaws.com"www.example.compute.amazonaws.com❌
"amazonaws.com"test.amazonaws.com✅At the time of writing, amazonaws.com is a registrable domain.
7.1.1.3 The Origin interface

The Origin interface represents an origin, allowing robust same origin and same site comparisons.

[Exposed=*]
interface Origin {
  constructor();

  static Origin from(any value);

  readonly attribute boolean opaque;

  boolean isSameOrigin(Origin other);
  boolean isSameSite(Origin other);
};

Origin objects have an associated origin, which holds an origin.

Platform objects have an extract an origin operation, which returns null unless otherwise specified.

Objects implementing the Origin interface's extract an origin steps are to return this's origin.

The new Origin() constructor steps are to set this's origin to a unique opaque origin.

The static from(value) method steps are:

  1. If value is a platform object:

    1. Let origin be the result of executing value's extract an origin operation.

    2. If origin is not null, then return a new Origin object whose origin is origin.

  2. If value is a string:

    1. Let parsedURL be the result of basic URL parsing value.

    2. If parsedURL is not failure, then return a new Origin object whose origin is set to parsedURL's origin.

  3. Throw a TypeError.

The opaque getter steps are to return true if this's origin is an opaque origin; otherwise false.

The isSameOrigin(other) method steps are to return true if this's origin is same origin with other's origin; otherwise false.

The isSameSite(other) method steps are to return true if this's origin is same site with other's origin; otherwise false.

7.1.2 Origin-keyed agent clusters

window.originAgentCluster

Returns true if this Window belongs to an agent cluster which is origin-keyed, in the manner described in this section.

A Document delivered over a secure context can request that it be placed in an origin-keyed agent cluster, by using the `Origin-Agent-Cluster` HTTP response header. This header is a structured header whose value must be a boolean. [STRUCTURED-FIELDS]

Per the processing model in the create and initialize a new Document object, values that are not the structured header boolean true value (i.e., `?1`) will be ignored.

The consequences of using this header are that the resulting Document's agent cluster key is its origin, instead of the corresponding site. In terms of observable effects, this means that attempting to relax the same-origin restriction using document.domain will instead do nothing, and it will not be possible to send WebAssembly.Module objects to cross-origin Documents (even if they are same site). Behind the scenes, this isolation can allow user agents to allocate implementation-specific resources corresponding to agent clusters, such as processes or threads, more efficiently.

Note that within a browsing context group, the `Origin-Agent-Cluster` header can never cause same-origin Document objects to end up in different agent clusters, even if one sends the header and the other doesn't. This is prevented by means of the historical agent cluster key map.

This means that the originAgentCluster getter can return false, even if the header is set, if the header was omitted on a previously-loaded same-origin page in the same browsing context group. Similarly, it can return true even when the header is not set.

The originAgentCluster getter steps are to return the surrounding agent's agent cluster's is origin-keyed.

Documents with an opaque origin can be considered unconditionally origin-keyed; for them the header has no effect, and the originAgentCluster getter will always return true.

Similarly, Documents whose agent cluster's cross-origin isolation mode is not "none" are automatically origin-keyed. The `Origin-Agent-Cluster` header might be useful as an additional hint to implementations about resource allocation, since the `Cross-Origin-Opener-Policy` and `Cross-Origin-Embedder-Policy` headers used to achieve cross-origin isolation are more about ensuring that everything in the same address space opts in to being there. But adding it would have no additional observable effects on author code.

7.1.3 Cross-origin opener policies

An opener policy value allows a document which is navigated to in a top-level browsing context to force the creation of a new top-level browsing context, and a corresponding group. The possible values are:

"unsafe-none"

This is the (current) default and means that the document will occupy the same top-level browsing context as its predecessor, unless that document specified a different opener policy.

"same-origin-allow-popups"

This forces the creation of a new top-level browsing context for the document, unless its predecessor specified the same opener policy and they are same origin.

"same-origin"

This behaves the same as "same-origin-allow-popups", with the addition that any auxiliary browsing context created needs to contain same origin documents that also have the same opener policy or it will appear closed to the opener.

"same-origin-plus-COEP"

This behaves the same as "same-origin", with the addition that it sets the (new) top-level browsing context's group's cross-origin isolation mode to one of "logical" or "concrete".

"same-origin-plus-COEP" cannot be directly set via the `Cross-Origin-Opener-Policy` header, but results from a combination of setting both `Cross-Origin-Opener-Policy: same-origin` and a `Cross-Origin-Embedder-Policy` header whose value is compatible with cross-origin isolation together.

"noopener-allow-popups"

This forces the creation of a new top-level browsing context for the document, regardless of its predecessor.

While including a noopener-allow-popups value severs the opener relationship between the document on which it is applied and its opener, it does not create a robust security boundary between those same-origin documents.

Other risks from same-origin applications include:

  • Same-origin requests fetching the document's content — could be mitigated through Fetch Metadata filtering. [FETCHMETADATA]

  • Same-origin framing - could be mitigated through X-Frame-Options or CSP frame-ancestors.

  • JavaScript accessible cookies - can be mitigated by ensuring all cookies are httponly.

  • localStorage access to sensitive data.

  • Service worker installation.

  • Cache API manipulation or access to sensitive data. [SW]

  • postMessage or