Origins

An origin is the combination of scheme, host, and port derived from a URL. Origins form the fundamental security boundary of the web platform. Two resources sharing the same origin are assumed to trust each other. Resources with different origins are isolated by default through the same-origin policy.

Table of Contents

Usage

The origin of https://www.example.re:443/docs is https://www.example.re:443. The path, query string, and fragment are not part of the origin.

Browsers use origins to enforce the same-origin policy, which prevents scripts on one origin from reading data returned by a different origin. This isolation protects authenticated sessions, private data, and internal resources from cross-origin access. CORS provides a controlled exception mechanism where servers explicitly opt in to cross-origin access.

Origin vs the Origin header

The concept of an origin as a security boundary is distinct from the HTTP Origin request header. The header communicates the origin of the request to the server, but the security model itself is enforced by the browser.

Origin components

An origin consists of three parts:

  • Scheme (protocol): http, https, ftp
  • Host: the full hostname, including subdomains (www.example.re, api.example.re)
  • Port: explicit or implied by the scheme (443 for HTTPS, 80 for HTTP)

When the port matches the scheme's default, browsers normalize the origin by omitting the port. https://example.re:443 and https://example.re resolve to the same origin.

Same-origin vs cross-origin

Two URLs are same-origin when their scheme, host, and port all match exactly. Any difference in one of these three components makes them cross-origin.

URL Relation to https://www.example.re
https://www.example.re/page Same-origin (path differs, origin matches)
https://www.example.re:443 Same-origin (port implied by HTTPS)
http://www.example.re Cross-origin (different scheme)
https://api.example.re Cross-origin (different host)
https://www.example.re:8080 Cross-origin (different port)
https://other.example.re Cross-origin (different host)

The same-origin check is strict. Subdomains like www.example.re and api.example.re are different origins, even though they share the same registrable domain.

Same-site vs same-origin

"Same-site" and "same-origin" are related but distinct concepts. Same-origin requires an exact match of scheme, host, and port. Same-site is broader: two URLs are same-site when they share the same scheme and the same registrable domain (also called eTLD+1).

Registrable domain (eTLD+1)

A registrable domain is the effective top-level domain (eTLD) plus one additional label. The eTLD is determined by the Public Suffix List, which tracks domain suffixes under which registrations are possible.

URL eTLD Registrable domain (eTLD+1)
https://www.example.re .re example.re
https://shop.example.re .re example.re
https://my.project.github.io .github.io project.github.io
https://example.co.uk .co.uk example.co.uk

Same-site comparison

URL A URL B Same-origin? Same-site?
https://www.example.re https://api.example.re No (different host) Yes (same scheme + eTLD+1)
https://www.example.re http://www.example.re No (different scheme) No (different scheme)
https://www.example.re https://www.example.re:8080 No (different port) Yes (port ignored for same-site)
https://example.re https://shop.other.re No No (different eTLD+1)

The same-site definition includes the scheme. An older "schemeless same-site" concept treated http and https as equivalent, but current specifications require scheme matching. This prevents HTTP from being used as an insecure channel alongside HTTPS.

Same-site checks ignore port

Unlike same-origin, same-site comparisons do not consider the port. Two URLs with the same scheme and eTLD+1 are same-site regardless of port differences.

SameSite cookies

The SameSite attribute on Cookies uses the same-site definition to control when cookies are sent with cross-site requests.

Value Behavior
Strict Cookie sent only in first-party context (site in address bar matches cookie site)
Lax Cookie sent on same-site requests and top-level navigations from external sites
None Cookie sent on all requests (requires Secure attribute)

Because same-site is broader than same-origin, SameSite=Strict cookies are still sent across subdomains. A cookie set on www.example.re with SameSite=Strict is sent with requests to api.example.re because both share the registrable domain example.re.

Opaque origins

Not all contexts produce a standard scheme/host/port origin. Some produce an opaque origin, a globally unique identifier with no accessible components. An opaque origin is never same-origin with any other origin, including another opaque origin.

Contexts producing opaque origins:

  • data: URLs loaded by scripts or navigation
  • Sandboxed iframes using the sandbox attribute without allow-same-origin
  • file: protocol pages in most browsers
  • javascript: URLs in certain contexts

The null origin

When serialized for the Origin HTTP header, opaque origins become the string null. A CORS request from a sandboxed iframe or data: URL sends Origin: null.

Allowing null origin with credentials

Servers must not combine Access-Control-Allow-Origin: null with Access-Control-Allow-Credentials: true. Because multiple unrelated contexts produce a null origin, allowing credentialed access to null is equivalent to allowing any sandboxed or data-URL context to read authenticated responses.

Sec-Fetch-Site header

Modern browsers include the Sec-Fetch-Site request header, which reports the relationship between the request origin and the target origin.

Value Meaning
same-origin Request origin and target origin match exactly
same-site Origins share the same scheme and eTLD+1
cross-site Origins differ in scheme or eTLD+1
none User-initiated navigation (typing URL, opening bookmark)

The Sec-Fetch-Site header is set by the browser and cannot be modified by JavaScript, making the value reliable for server-side policy decisions. The related headers Sec-Fetch-Dest, Sec-Fetch-Mode, and Sec-Fetch-User provide additional request context.

Example

A page at https://www.example.re makes a fetch() call to https://api.example.re/data. The browser determines this is a cross-origin, same-site request and includes the appropriate headers.

GET /data HTTP/1.1
Host: api.example.re
Origin: https://www.example.re
Sec-Fetch-Site: same-site
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty

The Origin header communicates the requesting origin. The Sec-Fetch-Site value same-site confirms both origins share the example.re registrable domain with the same https scheme.

Takeaway

An origin is the combination of scheme, host, and port from a URL. Same-origin requires an exact match of all three components. Same-site is a broader comparison based on scheme and registrable domain (eTLD+1), ignoring port and subdomains. Opaque origins produced by data: URLs, sandboxed iframes, and the file: protocol serialize to null and are never same-origin with anything. The Sec-Fetch-Site header reports the origin relationship on every request, enabling server-side policy enforcement.

See also

Last updated: March 4, 2026