RFC 6454

The Web Origin Concept

📅 published December 2011, from ietf

RFC 6454: The Web Origin Concept 🎀

Okay bestie, here's the deets 💖

  • Author: A. Barth, Google, Inc. 🧑‍💻
  • Category: Standards Track ✅
  • Date: December 2011 📅
  • ISSN: 2070-1721
  • Obsoletes / Updates: This title block doesn't list any documents it obsoletes or updates, so it's standing on its own 💅

Abstract 🌸

Okay so this doc defines the concept of an "origin" 🦋. User agents love using it as the scope of authority or privilege, and they usually isolate content from different origins so that shady site operators can't mess with the legit ones. Beyond the principles, it also explains how to figure out the origin of a URI and how to serialize an origin into a string. And it defines an HTTP header field called Origin that tells you which origins are linked to an HTTP request. Main character energy 👑

Status of This Memo 📜

This is an Internet Standards Track document ✨

This doc is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication 🫶 For more on Internet Standards, check Section 2 of RFC 5741.

Info about the current status of this document, any errata, and how to give feedback lives at http://www.rfc-editor.org/info/rfc6454 🔗

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 💜

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as in effect on the date of publication. Please review these carefully, bestie, because they explain your rights and restrictions for this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License. 🌈

Table of Contents 🗂️

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
    2.1.  Conformance Criteria . . . . . . . . . . . . . . . . . . .  3
    2.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  4
    2.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
  3.  Principles of the Same-Origin Policy . . . . . . . . . . . . .  4
    3.1.  Trust  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
      3.1.1.  Pitfalls . . . . . . . . . . . . . . . . . . . . . . .  5
    3.2.  Origin . . . . . . . . . . . . . . . . . . . . . . . . . .  6
      3.2.1.  Examples . . . . . . . . . . . . . . . . . . . . . . .  7
    3.3.  Authority  . . . . . . . . . . . . . . . . . . . . . . . .  7
      3.3.1.  Pitfalls . . . . . . . . . . . . . . . . . . . . . . .  8
    3.4.  Policy . . . . . . . . . . . . . . . . . . . . . . . . . .  8
      3.4.1.  Object Access  . . . . . . . . . . . . . . . . . . . .  8
      3.4.2.  Network Access . . . . . . . . . . . . . . . . . . . .  9
      3.4.3.  Pitfalls . . . . . . . . . . . . . . . . . . . . . . .  9
    3.5.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 10
  4.  Origin of a URI  . . . . . . . . . . . . . . . . . . . . . . . 10
  5.  Comparing Origins  . . . . . . . . . . . . . . . . . . . . . . 11
  6.  Serializing Origins  . . . . . . . . . . . . . . . . . . . . . 11
    6.1.  Unicode Serialization of an Origin . . . . . . . . . . . . 12
    6.2.  ASCII Serialization of an Origin . . . . . . . . . . . . . 12
  7.  The HTTP Origin Header Field . . . . . . . . . . . . . . . . . 13
    7.1.  Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 13
    7.2.  Semantics  . . . . . . . . . . . . . . . . . . . . . . . . 13
    7.3.  User Agent Requirements  . . . . . . . . . . . . . . . . . 14
  8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
    8.1.  Reliance on DNS  . . . . . . . . . . . . . . . . . . . . . 15
    8.2.  Divergent Units of Isolation . . . . . . . . . . . . . . . 15
    8.3.  Ambient Authority  . . . . . . . . . . . . . . . . . . . . 16
    8.4.  IDNA Dependency and Migration  . . . . . . . . . . . . . . 16
  9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
  10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
    10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
    10.2. Informative References . . . . . . . . . . . . . . . . . . 18
  Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 20

1. Introduction ✨

User agents interact with content made by a huge number of authors 🌍 Most of those authors are well-meaning, but some might be malicious 😈 To the extent that user agents take actions based on the content they process, user agent implementors might want to limit how much malicious authors can disrupt the confidentiality or integrity of other content or servers 🛡️

Let's make it concrete. Picture an HTTP user agent rendering HTML content pulled from various servers 🖥️ If that user agent runs the scripts inside those documents, the implementor might want to stop a script from a malicious server from reading documents stored on an honest server, which could, for example, be sitting behind a firewall 🔥

Traditionally, user agents have split content up by its "origin" 🦋 More specifically, content retrieved from one origin can interact freely with other content from that same origin, but user agents restrict how it can interact with content from a different origin 🚧

This document describes the principles behind the so-called same-origin policy, plus the "nuts and bolts" of comparing and serializing origins 🔩 It does not cover every facet of the same-origin policy. Those details are left to other specifications, like HTML [HTML] and WebSockets [RFC6455], because they're often application-specific 💜

2. Conventions 📐

2.1. Conformance Criteria

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 🧠

Requirements written in the imperative as part of algorithms (like "strip any leading space characters" or "return false and abort these steps") get the meaning of the key word ("MUST", "SHOULD", "MAY", etc.) that was used to introduce the algorithm 🎯

Conformance requirements phrased as algorithms or specific steps can be implemented in any manner, so long as the end result is equivalent ✨ The algorithms in this specification are meant to be easy to understand and are not meant to be performant 🙈

2.2. Syntax Notation

This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234]. 📝

The following core rules are included by reference, as defined in [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), HTAB (horizontal tab), CHAR (any US-ASCII character), VCHAR (any visible US-ASCII character), and WSP (whitespace). 🌸

The OWS rule is used where zero or more linear whitespace octets might appear. OWS SHOULD either not be produced or be produced as a single SP. Multiple OWS octets that occur within field-content SHOULD either be replaced with a single SP or transformed to all SP octets (each octet other than SP replaced with SP) before interpreting the field value or forwarding the message downstream. 💅

OWS            = *( SP / HTAB / obs-fold )
                  ; "optional" whitespace
obs-fold       = CRLF ( SP / HTAB )
                  ; obsolete line folding

2.3. Terminology

The terms "user agent", "client", "server", "proxy", and "origin server" have the same meaning as in the HTTP/1.1 specification ([RFC2616], Section 1.3). 📖

A globally unique identifier is a value that is different from all other previously existing values 🆔 For example, a sufficiently long random string is likely to be a globally unique identifier. If the origin value never leaves the user agent, a monotonically increasing counter local to the user agent can also serve as a globally unique identifier 🔢

3. Principles of the Same-Origin Policy 🏰

Many user agents take actions on behalf of remote parties 🤝 For example, HTTP user agents follow redirects, which are instructions from remote servers, and HTML user agents expose rich Document Object Model (DOM) interfaces to scripts retrieved from remote servers 🧚

Without any security model, user agents might take actions that are detrimental to the user or to other parties 😬 Over time, many web-related technologies have converged on a common security model, known colloquially as the "same-origin policy" 💖 Even though this model evolved mostly organically, the same-origin policy can be understood through a handful of key concepts. This section walks through those concepts and gives advice on how to use them securely 🫶

3.1. Trust

The same-origin policy specifies trust by URI. For example, HTML documents designate which script to run with a URI 🔗

<script src="https://example.com/library.js"></script>

When a user agent processes this element, it fetches the script at the designated URI and executes the script with the privileges of the document 🚀 In this way, the document grants all the privileges it has to the resource designated by the URI. In essence, the document declares that it trusts the integrity of information retrieved from that URI 🤍

User agents also send information to remote parties designated by URI, not just import libraries from them 📤 For example, consider the HTML form element:

<form method="POST" action="https://example.com/login">
 ... <input type="password"> ...
</form>

When the user enters their password and submits the form, the user agent sends the password to the network endpoint designated by the URI 🔐 In this way, the document exports its secret data to that URI, which is basically declaring that it trusts the confidentiality of information sent to that URI 🥹

3.1.1. Pitfalls 🕳️

When designing new protocols that use the same-origin policy, make sure that important trust distinctions are visible in URIs 🚨 For example, if both Transport Layer Security (TLS) and non-TLS protected resources use the "http" URI scheme (as in [RFC2817]), a document would be unable to specify that it wishes to retrieve a script only over TLS. By using the "https" URI scheme, documents are able to indicate that they wish to interact with resources that are protected from active network attackers 🛡️💀

3.2. Origin ✨

okay so in theory, user agents could treat every single URI as its own little protection bubble 🫧 and demand explicit consent every time content from one URI wants to talk to another one. but ngl that's giving nightmare for developers, because web apps are usually a bunch of resources working together as a team 🫶

so instead, user agents group URIs together into protection domains called "origins" 👑 roughly speaking, two URIs are part of the same origin (i.e., represent the same principal) if they have the same scheme, host, and port. (See Section 4 for full details.) 🦋

Q: Why not just use the host? 🤔

A: including the scheme in the origin tuple is essential for security 🔥 if user agents didn't include the scheme, there would be zero isolation between http://example.com and https://example.com, because the two have the same host. and without that isolation, an active network attacker could corrupt content retrieved from http://example.com and have that content tell the user agent to mess with the confidentiality and integrity of content retrieved from https://example.com 💀 basically bypassing the protections TLS gives you [RFC5246]. not it. 🙅‍♀️

Q: Why use the fully qualified host name instead of just the "top-level" domain? 🌸

A: okay so DNS has hierarchical delegation, but the trust relationships between host names vary by deployment 🌈 for example, at lots of educational institutions, students can host content at https://example.edu/~student/, but that does NOT mean a document written by a student should be part of the same origin (i.e., inhabit the same protection domain) as a web app for managing grades hosted at https://grades.example.edu/ 😭

the example.edu deployment shows that grouping resources by origin doesn't always line up perfectly with every deployment scenario 🙈 in this setup, every student's website lives in the same origin, which might not be desirable. honestly the origin granularity is kind of a historical artifact of how the security model evolved 🧚

3.2.1. Examples 💅

All of the following resources have the same origin:

http://example.com/
http://example.com:80/
http://example.com/path/file

Each of the URIs has the same scheme, host, and port components. ✨

Each of the following resources has a different origin from the others. 🍓

http://example.com/
http://example.com:8080/
http://www.example.com/
https://example.com:80/
https://example.com/
http://example.org/
http://ietf.org/

In each case, at least one of the scheme, host, and port components will differ from the others in the list. 💜

3.3. Authority 👑

Although user agents group URIs into origins, not every resource in an origin carries the same authority (in the security sense of the word "authority", not in the [RFC3986] sense) 🙃 for example, an image is passive content, so it carries no authority. that means the image has no access to the objects and resources available to its origin. 🖼️ by contrast, an HTML document carries the full authority of its origin, and scripts within (or imported into) the document can access every resource in its origin. main character energy 😤✨

user agents figure out how much authority to hand a resource by checking its media type 🎀 for example, resources with a media type of image/png are treated as images, and resources with a media type of text/html are treated as HTML documents.

when hosting untrusted content (like user-generated content), web apps can limit that content's authority by restricting its media type 🧁 for example, serving user-generated content as image/png is less risky than serving it as text/html. of course, lots of web apps stick untrusted content inside their HTML documents anyway 🫠 and if that's not done carefully, those apps risk leaking their origin's authority to the untrusted content. this is a vulnerability commonly known as cross-site scripting. this is the stuff that keeps security people up at night 😱

3.3.1. Pitfalls ⚠️

when you're designing new pieces of the web platform, be careful not to grant authority to resources irrespective of media type 🚫 lots of web apps serve untrusted content with restricted media types. a new web platform feature that grants authority to those pieces of content risks introducing vulnerabilities into existing apps 💀 instead, prefer to grant authority to media types that already have the origin's full authority, or to new media types designed specifically to carry the new authority. 🧠

also, to stay compatible with servers that send incorrect media types, some user agents do "content sniffing" and treat content as if it had a different media type than the one the server supplied 🕵️‍♀️ if that's not done carefully, content sniffing can lead to security vulnerabilities, because user agents might give low-authority media types (like images) the privileges of high-authority media types (like HTML documents) [SNIFF]. chaotic. 😵‍💫

3.4. Policy 📜

generally speaking, user agents isolate different origins and allow controlled communication between origins 🦋 the details of how they do the isolation and communication vary depending on several factors. it's a whole vibe 🌈

3.4.1. Object Access 🎀

most objects (also known as application programming interfaces or APIs) exposed by the user agent are only available to the same origin 🔒 specifically, content retrieved from one URI can access objects associated with content retrieved from another URI if, and only if, the two URIs belong to the same origin (e.g., have the same scheme, host, and port). if and only if 💅

there are some exceptions to this general rule 🙃 for example, some parts of HTML's Location interface are available across origins (e.g., to allow navigating other browsing contexts). and HTML's postMessage interface is visible across origins on purpose, to facilitate cross-origin communication 📨 exposing objects to foreign origins is dangerous, so it should only be done with great care, because it exposes those objects to potential attackers. 😬

3.4.2. Network Access 🌐

access to network resources depends on whether the resources are in the same origin as the content trying to access them 🧐

generally, reading information from another origin is forbidden 🚫 however, an origin is permitted to use some kinds of resources retrieved from other origins. for example, an origin is permitted to execute script, render images, and apply style sheets from any origin ✨ likewise, an origin can display content from another origin, such as an HTML document in an HTML frame 🖼️ network resources can also opt into letting other origins read their information, for example, using Cross-Origin Resource Sharing [CORS]. in these cases, access is typically granted on a per-origin basis. 🫶

sending information to another origin is permitted 📤 however, sending information over the network in arbitrary formats is dangerous 💀 for this reason, user agents restrict documents to sending information using particular protocols, such as in an HTTP request without custom headers. expanding the set of allowed protocols (for example, by adding support for WebSockets) must be done carefully to avoid introducing vulnerabilities [RFC6455]. be careful out there bestie 🧦

3.4.3. Pitfalls 🫣

whenever user agents let one origin interact with resources from another origin, they invite security issues 🙈 for example, the ability to display images from another origin leaks their height and width. similarly, the ability to send network requests to another origin gives rise to cross-site request forgery vulnerabilities [CSRF]. HOWEVER, user agent implementors often balance these risks against the benefits of allowing the cross-origin interaction ⚖️ for example, an HTML user agent that blocked cross-origin network requests would stop its users from following hyperlinks, which is a core feature of the web. so it's a trade-off, no cap 🔥

when adding new functionality to the web platform, it can be tempting to grant a privilege to one resource but withhold it from another resource in the same origin 😏 however, withholding privileges like that is ineffective, because the resource without the privilege can usually get the privilege anyway, since user agents don't isolate resources within an origin 🙅‍♀️ instead, privileges should be granted or withheld from origins as a whole (rather than discriminating between individual resources within an origin) [BOFGO]. origin-level, always. 💖

3.5. Conclusion 🎉

the same-origin policy uses URIs to designate trust relationships 🪪 URIs get grouped into origins, which represent protection domains. some resources in an origin (e.g., active content) are granted the origin's full authority, whereas other resources in the origin (e.g., passive content) are not 🌸 content that carries its origin's authority gets access to objects and network resources within its own origin. it also gets limited access to objects and network resources of other origins, but those cross-origin privileges must be designed carefully to avoid security vulnerabilities. that's the whole tea, bestie 🌈💅✨

4. Origin of a URI ✨

okay bestie, so here's how you work out the origin of a URI 🍓 it's a little algorithm, and it goes like this:

  1. If the URI does not use a hierarchical element as a naming authority (see [RFC3986], Section 3.2) or if the URI is not an absolute URI, then generate a fresh globally unique identifier and return that value.
NOTE: Running this algorithm multiple times for the same URI can produce different values each time. Typically, user agents compute the origin of, for example, an HTML document once and use that origin for subsequent security checks rather than recomputing the origin for each security check. 💅
  1. Let uri-scheme be the scheme component of the URI, converted to lowercase.
  2. If the implementation doesn't support the protocol given by uri-scheme, then generate a fresh globally unique identifier and return that value.
  3. If uri-scheme is file, the implementation MAY return an implementation-defined value.
NOTE: Historically, user agents have granted content from the file scheme a tremendous amount of privilege. However, granting all local files such wide privileges can lead to privilege escalation attacks. Some user agents have had success granting local files directory-based privileges, but this approach has not been widely adopted. Other user agents use globally unique identifiers for each file URI, which is the most secure option. 🔥
  1. Let uri-host be the host component of the URI, converted to lower case (using the i;ascii-casemap collation defined in [RFC4790]).
NOTE: This document assumes that the user agent performs Internationalizing Domain Names in Applications (IDNA) processing and validation when constructing the URI. In particular, this document assumes the uri-host will contain only LDH labels because the user agent will have already converted any non-ASCII labels to their corresponding A-labels (see [RFC5890]). For this reason, origin-based security policies are sensitive to the IDNA algorithm employed by the user agent. See Section 8.4 for further discussion. 🦋
  1. If there is no port component of the URI:
    1. Let uri-port be the default port for the protocol given by uri-scheme.

Otherwise:

  1. Let uri-port be the port component of the URI.
  1. Return the triple (uri-scheme, uri-host, uri-port). 🎀

5. Comparing Origins

Two origins are "the same" if, and only if, they are identical. In particular:

  • If the two origins are scheme/host/port triples, the two origins are the same if, and only if, they have identical schemes, hosts, and ports.
  • An origin that is a globally unique identifier cannot be the same as an origin that is a scheme/host/port triple.

Two URIs are same-origin if their origins are the same.

NOTE: A URI is not necessarily same-origin with itself. For example, a data URI [RFC2397] 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. 🙈

6. Serializing Origins 🌸

This section defines how to serialize an origin to a unicode [Unicode6] string and to an ASCII [RFC20] string.

6.1. Unicode Serialization of an Origin

The unicode-serialization of an origin is the value returned by the following algorithm:

  1. If the origin is not a scheme/host/port triple, then return the string

null

(i.e., the code point sequence U+006E, U+0075, U+006C, U+006C) and abort these steps.

  1. Otherwise, let result be the scheme part of the origin triple.
  2. Append the string :// to result.
  3. Append each component of the host part of the origin triple (converted as follows) to the result, separated by U+002E FULL STOP code points (.):
    1. If the component is an A-label, use the corresponding U-label instead (see [RFC5890] and [RFC5891]).
    2. Otherwise, use the component verbatim.
  4. If the port part of the origin triple is different from the default port for the protocol given by the scheme part of the origin triple:
    1. Append a U+003A COLON code point (:) and the given port, in base ten, to result.
  5. Return result.

6.2. ASCII Serialization of an Origin

The ascii-serialization of an origin is the value returned by the following algorithm:

  1. If the origin is not a scheme/host/port triple, then return the string

null

(i.e., the code point sequence U+006E, U+0075, U+006C, U+006C) and abort these steps.

  1. Otherwise, let result be the scheme part of the origin triple.
  2. Append the string :// to result.
  3. Append the host part of the origin triple to result.
  4. If the port part of the origin triple is different from the default port for the protocol given by the scheme part of the origin triple:
    1. Append a U+003A COLON code point (:) and the given port, in base ten, to result.
  5. Return result.

7. The HTTP Origin Header Field 🧚

This section defines the HTTP Origin header field. Let's get into it!

7.1. Syntax

The Origin header field has the following syntax:

origin              = "Origin:" OWS origin-list-or-null OWS
origin-list-or-null = %x6E %x75 %x6C %x6C / origin-list
origin-list         = serialized-origin *( SP serialized-origin )
serialized-origin   = scheme "://" host [ ":" port ]
                      ; <scheme>, <host>, <port> from RFC 3986

7.2. Semantics

When included in an HTTP request, the Origin header field indicates the origin(s) that "caused" the user agent to issue the request, as defined by the API that triggered the user agent to issue the request. 👑

For example, consider a user agent that executes scripts on behalf of origins. If one of those scripts causes the user agent to issue an HTTP request, the user agent MAY use the Origin header field to inform the server of the security context in which the script was executing when it caused the user agent to issue the request.

In some cases, a number of origins contribute to causing the user agents to issue an HTTP request. In those cases, the user agent MAY list all the origins in the Origin header field. For example, if the HTTP request was initially issued by one origin but then later redirected by another origin, the user agent MAY inform the server that two origins were involved in causing the user agent to issue the request. ✨

7.3. User Agent Requirements

The user agent MAY include an Origin header field in any HTTP request.

The user agent MUST NOT include more than one Origin header field in any HTTP request. 🙅‍♀️

Whenever a user agent issues an HTTP request from a "privacy-sensitive" context, the user agent MUST send the value "null" in the Origin header field.

NOTE: This document does not define the notion of a privacy-sensitive context. Applications that generate HTTP requests can designate contexts as privacy-sensitive to impose restrictions on how user agents generate Origin header fields. 🔒

When generating an Origin header field, the user agent MUST meet the following requirements:

  • Each of the serialized-origin productions in the grammar MUST be the ascii-serialization of an origin.
  • No two consecutive serialized-origin productions in the grammar can be identical. In particular, if the user agent would generate two consecutive serialized-origins, the user agent MUST NOT generate the second one. 💜

8. Security Considerations 💀

The same-origin policy is one of the cornerstones of security for many user agents, including web browsers. Historically, some user agents tried other security models, including taint tracking and exfiltration prevention, but those models proved difficult to implement at the time (although there has been recent interest in reviving some of these ideas).

Evaluating the security of the same-origin policy is difficult because the origin concept itself plays such a central role in the security landscape. The notional origin itself is just a unit of isolation, imperfect as are most one-size-fits-all notions. That said, there are some systemic weaknesses, discussed below. 😭

8.1. Reliance on DNS

In practice, the same-origin policy relies upon the Domain Name System (DNS) for security because many commonly used URI schemes, such as http, use DNS-based naming authorities. If the DNS is partially or fully compromised, the same-origin policy might fail to provide the security properties required by applications. 🥺

Some URI schemes, such as https, are more resistant to DNS compromise because user agents employ other mechanisms, such as certificates, to verify the source of content retrieved from these URIs. Other URI schemes, such as the chrome-extension URI scheme (see Section 4.3 of [CRX]), use a public-key-based naming authority and are fully secure against DNS compromise. 🔐

The web origin concept isolates content retrieved from different URI schemes; this is essential to containing the effects of DNS compromise. 🛡️

8.2. Divergent Units of Isolation

Over time, a number of technologies have converged on the web origin concept as a convenient unit of isolation. However, many technologies in use today, such as cookies [RFC6265], pre-date the modern web origin concept. These technologies often have different isolation units, leading to vulnerabilities. 🫠

One alternative is to use only the "registry-controlled" domain rather than the fully qualified domain name as the unit of isolation (e.g., example.com instead of www.example.com). This practice is problematic for a number of reasons and is NOT RECOMMENDED:

  1. The notion of a "registry-controlled" domain is a function of human practice surrounding the DNS rather than a property of the DNS itself. For example, many municipalities in Japan run public registries quite deep in the DNS hierarchy. There are widely used "public suffix lists", but these lists are difficult to keep up to date and vary between implementations.
  2. This practice is incompatible with URI schemes that do not use a DNS-based naming authority. For example, if a given URI scheme uses public keys as naming authorities, the notion of a "registry-controlled" public key is somewhat incoherent. Worse, some URI schemes, such as nntp, use dotted delegation in the opposite direction from DNS (e.g., alt.usenet.kooks), and others use the DNS but present the labels in the reverse of the usual order (e.g., com.example.www).

At best, using "registry-controlled" domains is URI-scheme- and implementation-specific. At worst, differences between URI schemes and implementations can lead to vulnerabilities. yikes, not worth the risk 🚨

8.3. Ambient Authority 🦋

okay so, when you're using the same-origin policy, user agents hand out authority to content based on its URI, NOT based on which objects the content can point at. ngl this split between "what you can name" and "what you're allowed to do" is a classic example of ambient authority, and it can lead to real vulnerabilities 😭

picture cross-site scripting in HTML documents. if an attacker manages to inject script into an HTML document, that script runs with the authority of the document's origin 💀 which means it could get into sensitive stuff, like the user's medical records. but if the script's authority were limited to only the objects it could actually designate, the attacker wouldn't gain anything by injecting the script into an HTML document hosted by a third party. the vibe check is that the damage is way bigger because the authority is tied to the origin and not the reference 🙈

8.4. IDNA Dependency and Migration 💅

the security properties of the same-origin policy can depend HEAVILY on the details of the IDNA algorithm the user agent uses 🔥 like, a user agent might map some international domain names (for example, ones involving the U+00DF character) to different ASCII representations depending on whether it's using IDNA2003 [RFC3490] or IDNA2008 [RFC5890]. the same domain name can end up somewhere totally different depending on which one is in play 👀

migrating from one IDNA algorithm to another might redraw a bunch of security boundaries 🧚 it could put up brand new security boundaries or, worse, tear down boundaries between two entities that don't trust each other. changing security boundaries is risky because combining two mutually distrusting entities into the same origin might let one of them attack the other. so be careful, bestie, this is a whole vibe 🌈

9. IANA Considerations 🌸

the permanent message header field registry (see [RFC3864]) has been updated with the following registration:

  • Header field name: Origin
  • Applicable protocol: http
  • Status: standard
  • Author/Change controller: IETF
  • Specification document: this specification (Section 7)

10. References 📚

10.1. Normative References

  • [RFC20] Cerf, V., "ASCII format for network interchange", RFC 20, October 1969.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
  • [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
  • [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
  • [RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet Application Protocol Collation Registry", RFC 4790, March 2007.
  • [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
  • [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
  • [RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
  • [Unicode6] The Unicode Consortium, "The Unicode Standard, Version 6.0.0", 2011, http://www.unicode.org/versions/Unicode6.0.0/.

10.2. Informative References

Appendix A. Acknowledgements 🫶

we'd like to thank Lucas Adamski, Stephen Farrell, Miguel A. Garcia, Tobias Gondrom, Ian Hickson, Anne van Kesteren, Jeff Hodges, Collin Jackson, Larry Masinter, Alexey Melnikov, Mark Nottingham, Julian Reschke, Peter Saint-Andre, Jonas Sicking, Sid Stamm, Daniel Veditz, and Chris Weber for their valuable feedback on this document 💜✨

Author's Address 🎀

Adam Barth Google, Inc.

EMail: ietf@adambarth.com URI: http://www.adambarth.com/

📦 where this page comes from