draft-ietf-websec-origin-06.txt   rfc6454.txt 
websec A. Barth Internet Engineering Task Force (IETF) A. Barth
Internet-Draft Google, Inc. Request for Comments: 6454 Google, Inc.
Intended status: Standards Track October 3, 2011 Category: Standards Track December 2011
Expires: April 5, 2012 ISSN: 2070-1721
The Web Origin Concept The Web Origin Concept
draft-ietf-websec-origin-06
Abstract Abstract
This document defines the concept of an "origin", which is often used This document defines the concept of an "origin", which is often used
as the scope of authority or privilege by user agents. Typically, as the scope of authority or privilege by user agents. Typically,
user agents isolate content retrieved from different origins to user agents isolate content retrieved from different origins to
prevent malicious web site operators from interfering with the prevent malicious web site operators from interfering with the
operation of benign web sites. In addition to outlining the operation of benign web sites. In addition to outlining the
principles that underlie the concept of origin, this document defines principles that underlie the concept of origin, this document details
how to determine the origin of a URI, how to serialize an origin into how to determine the origin of a URI and how to serialize an origin
a string, and an HTTP header field, named "Origin", that indicates into a string. It also defines an HTTP header field, named "Origin",
which origins are associated with an HTTP request. that indicates which origins are associated with an HTTP request.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on April 5, 2012. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6454.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . . 4 2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . . 3
2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4
2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Principles of the Same-Origin Policy . . . . . . . . . . . . . 6 3. Principles of the Same-Origin Policy . . . . . . . . . . . . . 4
3.1. Trust . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Trust . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.1. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Origin . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Origin . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Authority . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Authority . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3.1. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . 9 3.3.1. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.4. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4.1. Object Access . . . . . . . . . . . . . . . . . . . . 9 3.4.1. Object Access . . . . . . . . . . . . . . . . . . . . 8
3.4.2. Network Access . . . . . . . . . . . . . . . . . . . . 10 3.4.2. Network Access . . . . . . . . . . . . . . . . . . . . 9
3.4.3. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . 10 3.4.3. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . 9
3.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 11 3.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Origin of a URI . . . . . . . . . . . . . . . . . . . . . . . 12 4. Origin of a URI . . . . . . . . . . . . . . . . . . . . . . . 10
5. Comparing Origins . . . . . . . . . . . . . . . . . . . . . . 14 5. Comparing Origins . . . . . . . . . . . . . . . . . . . . . . 11
6. Serializing Origins . . . . . . . . . . . . . . . . . . . . . 15 6. Serializing Origins . . . . . . . . . . . . . . . . . . . . . 11
6.1. Unicode Serialization of an Origin . . . . . . . . . . . . 15 6.1. Unicode Serialization of an Origin . . . . . . . . . . . . 12
6.2. ASCII Serialization of an Origin . . . . . . . . . . . . . 15 6.2. ASCII Serialization of an Origin . . . . . . . . . . . . . 12
7. The HTTP Origin header field . . . . . . . . . . . . . . . . . 17 7. The HTTP Origin Header Field . . . . . . . . . . . . . . . . . 13
7.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 17 7.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 13
7.3. User Agent Requirements . . . . . . . . . . . . . . . . . 17 7.3. User Agent Requirements . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8.1. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 19 8.1. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 15
8.2. Divergent Units of Isolation . . . . . . . . . . . . . . . 19 8.2. Divergent Units of Isolation . . . . . . . . . . . . . . . 15
8.3. Ambient Authority . . . . . . . . . . . . . . . . . . . . 20 8.3. Ambient Authority . . . . . . . . . . . . . . . . . . . . 16
8.4. IDNA dependency and migration . . . . . . . . . . . . . . 20 8.4. IDNA Dependency and Migration . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9.1. Origin . . . . . . . . . . . . . . . . . . . . . . . . . . 22 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 10.2. Informative References . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . . 23 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 20
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
User agents interact with content created by a large number of User agents interact with content created by a large number of
authors. Although many of those authors are well-meaning, some authors. Although many of those authors are well-meaning, some
authors might be malicious. To the extent that user agents undertake authors might be malicious. To the extent that user agents undertake
actions based on content they process, user agent implementors might actions based on content they process, user agent implementors might
wish to restrict the ability of malicious authors to disrupt the wish to restrict the ability of malicious authors to disrupt the
confidentiality or integrity of other content or servers. confidentiality or integrity of other content or servers.
skipping to change at page 3, line 31 skipping to change at page 3, line 31
Traditionally, user agents have divided content according to its Traditionally, user agents have divided content according to its
"origin". More specifically, user agents allow content retrieved "origin". More specifically, user agents allow content retrieved
from one origin to interact freely with other content retrieved from from one origin to interact freely with other content retrieved from
that origin, but user agents restrict how that content can interact that origin, but user agents restrict how that content can interact
with content from another origin. with content from another origin.
This document describes the principles behind the so-called same- This document describes the principles behind the so-called same-
origin policy as well as the "nuts and bolts" of comparing and origin policy as well as the "nuts and bolts" of comparing and
serializing origins. This document does not describe all the facets serializing origins. This document does not describe all the facets
of the same-origin policy, the details of which are left to other of the same-origin policy, the details of which are left to other
specifications, such as HTML [HTML] and WebSockets [WEBSOCKETS], specifications, such as HTML [HTML] and WebSockets [RFC6455], because
because the details are often application-specific. the details are often application-specific.
2. Conventions 2. Conventions
2.1. Conformance Criteria 2.1. Conformance Criteria
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Requirements phrased in the imperative as part of algorithms (such as Requirements phrased in the imperative as part of algorithms (such as
"strip any leading space characters" or "return false and abort these "strip any leading space characters" or "return false and abort these
steps") are to be interpreted with the meaning of the key word steps") are to be interpreted with the meaning of the key word
("MUST", "SHOULD", "MAY", etc) used in introducing the algorithm. ("MUST", "SHOULD", "MAY", etc.) used in introducing the algorithm.
Conformance requirements phrased as algorithms or specific steps can Conformance requirements phrased as algorithms or specific steps can
be implemented in any manner, so long as the end result is be implemented in any manner, so long as the end result is
equivalent. In particular, the algorithms defined in this equivalent. In particular, the algorithms defined in this
specification are intended to be easy to understand and are not specification are intended to be easy to understand and are not
intended to be performant. intended to be performant.
2.2. Syntax Notation 2.2. Syntax Notation
This specification uses the Augmented Backus-Naur Form (ABNF) This specification uses the Augmented Backus-Naur Form (ABNF)
skipping to change at page 5, line 7 skipping to change at page 4, line 32
octets (each octet other than SP replaced with SP) before octets (each octet other than SP replaced with SP) before
interpreting the field value or forwarding the message downstream. interpreting the field value or forwarding the message downstream.
OWS = *( SP / HTAB / obs-fold ) OWS = *( SP / HTAB / obs-fold )
; "optional" whitespace ; "optional" whitespace
obs-fold = CRLF ( SP / HTAB ) obs-fold = CRLF ( SP / HTAB )
; obsolete line folding ; obsolete line folding
2.3. Terminology 2.3. Terminology
The terms user agent, client, server, proxy, and origin server have The terms "user agent", "client", "server", "proxy", and "origin
the same meaning as in the HTTP/1.1 specification ([RFC2616], Section server" have the same meaning as in the HTTP/1.1 specification
1.3). ([RFC2616], Section 1.3).
A globally unique identifier is a value which is different from all A globally unique identifier is a value that is different from all
other previously existing values. For example, a sufficiently long other previously existing values. For example, a sufficiently long
random string is likely to be a globally unique identifier. If the random string is likely to be a globally unique identifier. If the
origin value never leaves the user agent, a monotonically increasing origin value never leaves the user agent, a monotonically increasing
counter local to the user agent can also serve as a globally unique counter local to the user agent can also serve as a globally unique
identifier identifier.
3. Principles of the Same-Origin Policy 3. Principles of the Same-Origin Policy
Many user agents undertake actions on behalf of remote parties. For Many user agents undertake actions on behalf of remote parties. For
example, HTTP user agents follow redirects, which are instructions example, HTTP user agents follow redirects, which are instructions
from remote servers and HTML user agents expose rich DOM interfaces from remote servers, and HTML user agents expose rich Document Object
to scripts retrieved from remote servers. Model (DOM) interfaces to scripts retrieved from remote servers.
Without any security model, user agents might undertake actions Without any security model, user agents might undertake actions
detrimental to the user or to other parties. Over time, many web- detrimental to the user or to other parties. Over time, many web-
related technologies have converged towards a common security model, related technologies have converged towards a common security model,
known colloquially as the "same-origin policy". Although this known colloquially as the "same-origin policy". Although this
security model evolved largely organically, the same-origin policy security model evolved largely organically, the same-origin policy
can be understood in terms of a handful of key concepts. This can be understood in terms of a handful of key concepts. This
section presents those concepts and provides advice about how to use section presents those concepts and provides advice about how to use
these concepts securely. these concepts securely.
skipping to change at page 7, line 9 skipping to change at page 5, line 42
When the user enters his or her password and submits the form, the When the user enters his or her password and submits the form, the
user agent sends the password to the network endpoint designated by user agent sends the password to the network endpoint designated by
the URI. In this way, the document exports its secret data to that the URI. In this way, the document exports its secret data to that
URI, in essence declaring that it trusts the confidentiality of URI, in essence declaring that it trusts the confidentiality of
information sent to that URI. information sent to that URI.
3.1.1. Pitfalls 3.1.1. Pitfalls
When designing new protocols that use the same-origin policy, make When designing new protocols that use the same-origin policy, make
sure that important trust distinctions are visible in URIs. For sure that important trust distinctions are visible in URIs. For
example, if both TLS and non-TLS protected resources used the "http" example, if both Transport Layer Security (TLS) and non-TLS protected
URI scheme (as in [RFC2817]), a document would be unable to specify resources use the "http" URI scheme (as in [RFC2817]), a document
that it wished to retrieve a script only over TLS. By using the would be unable to specify that it wishes to retrieve a script only
"https" URI scheme, documents are able to indicate that they wish to over TLS. By using the "https" URI scheme, documents are able to
interact with resources that are protected from active network indicate that they wish to interact with resources that are protected
attackers. from active network attackers.
3.2. Origin 3.2. Origin
In principle, user agents could treat every URI as a separate In principle, user agents could treat every URI as a separate
protection domain and require explicit consent for content retrieved protection domain and require explicit consent for content retrieved
from one URI to interact with another URI. Unfortunately, this from one URI to interact with another URI. Unfortunately, this
design is cumbersome for developers because web applications often design is cumbersome for developers because web applications often
consist of a number of resources acting in concert. consist of a number of resources acting in concert.
Instead, user agents group URIs together into protection domains Instead, user agents group URIs together into protection domains
skipping to change at page 8, line 5 skipping to change at page 6, line 43
A: Although the DNS has hierarchical delegation, the trust A: Although the DNS has hierarchical delegation, the trust
relationships between host names vary by deployment. For example, at relationships between host names vary by deployment. For example, at
many educational institutions, students can host content at many educational institutions, students can host content at
https://example.edu/~student/, but that does not mean a document https://example.edu/~student/, but that does not mean a document
authored by a student should be part of the same origin (i.e., authored by a student should be part of the same origin (i.e.,
inhabit the same protection domain) as a web application for managing inhabit the same protection domain) as a web application for managing
grades hosted at https://grades.example.edu/. grades hosted at https://grades.example.edu/.
The example.edu deployment illustrates that grouping resources by The example.edu deployment illustrates that grouping resources by
origin does not always align perfectly with every deployment origin does not always align perfectly with every deployment
scenario. In this deployment every student's web site inhabits the scenario. In this deployment, every student's web site inhabits the
same origin, which might not be desirable. In some sense, the origin same origin, which might not be desirable. In some sense, the origin
granularity is a historical artifact of how the security model granularity is a historical artifact of how the security model
evolved. evolved.
3.2.1. Examples 3.2.1. Examples
All of the following resources have the same origin: All of the following resources have the same origin:
http://example.com/ http://example.com/
http://example.com:80/ http://example.com:80/
skipping to change at page 8, line 42 skipping to change at page 7, line 37
will differ from the others in the list. will differ from the others in the list.
3.3. Authority 3.3. Authority
Although user agents group URIs into origins, not every resource in Although user agents group URIs into origins, not every resource in
an origin carries the same authority (in the security sense of the an origin carries the same authority (in the security sense of the
word "authority", not in the [RFC3986] sense). For example, an image word "authority", not in the [RFC3986] sense). For example, an image
is passive content and, therefore, carries no authority, meaning the is passive content and, therefore, carries no authority, meaning the
image has no access to the objects and resources available to its image has no access to the objects and resources available to its
origin. By contrast, an HTML document carries the full authority of origin. By contrast, an HTML document carries the full authority of
its origin and scripts within (or imported into) the document can its origin, and scripts within (or imported into) the document can
access every resource in its origin. access every resource in its origin.
User agents determine how much authority to grant a resource by User agents determine how much authority to grant a resource by
examining its media type. For example, resources with a media type examining its media type. For example, resources with a media type
of image/png are treated as images and resources with a media type of of image/png are treated as images, and resources with a media type
text/html are treated as HTML documents. of text/html are treated as HTML documents.
When hosting untrusted content (such as user-generated content), web When hosting untrusted content (such as user-generated content), web
applications can limit that content's authority by restricting its applications can limit that content's authority by restricting its
media type. For example, serving user-generated content as image/png media type. For example, serving user-generated content as image/png
is less risky than serving user-generated content as text/html. Of is less risky than serving user-generated content as text/html. Of
course many web applications incorporate untrusted content in their course, many web applications incorporate untrusted content in their
HTML documents. If not done carefully, these applications risk HTML documents. If not done carefully, these applications risk
leaking their origin's authority to the untrusted content, a leaking their origin's authority to the untrusted content, a
vulnerability commonly known as cross-site scripting. vulnerability commonly known as cross-site scripting.
3.3.1. Pitfalls 3.3.1. Pitfalls
When designing new pieces of the web platform, be careful not to When designing new pieces of the web platform, be careful not to
grant authority to resources irrespective of media type. Many web grant authority to resources irrespective of media type. Many web
applications serve untrusted content with restricted media types. A applications serve untrusted content with restricted media types. A
new web platform feature that grants authority to these pieces of new web platform feature that grants authority to these pieces of
skipping to change at page 9, line 47 skipping to change at page 8, line 37
controlled communication between origins. The details of how user controlled communication between origins. The details of how user
agents provide isolation and communication vary depending on several agents provide isolation and communication vary depending on several
factors. factors.
3.4.1. Object Access 3.4.1. Object Access
Most objects (also known as application programming interfaces or Most objects (also known as application programming interfaces or
APIs) exposed by the user agent are available only to the same APIs) exposed by the user agent are available only to the same
origin. Specifically, content retrieved from one URI can access origin. Specifically, content retrieved from one URI can access
objects associated with content retrieved from another URI if, and objects associated with content retrieved from another URI if, and
only if, the two URIs belong to the same origin, e.g., have same only if, the two URIs belong to the same origin, e.g., have the same
scheme, host, and port. scheme, host, and port.
There are some exceptions to this general rule. For example, some There are some exceptions to this general rule. For example, some
parts of HTML's Location interface are available across origins parts of HTML's Location interface are available across origins
(e.g., to allow for navigating other browsing contexts). As another (e.g., to allow for navigating other browsing contexts). As another
example, HTML's postMessage interface is visible across origins example, HTML's postMessage interface is visible across origins
explicitly to facilitate cross-origin communication. Exposing explicitly to facilitate cross-origin communication. Exposing
objects to foreign origins is dangerous and should be done only with objects to foreign origins is dangerous and should be done only with
great care because doing so exposes these objects to potential great care because doing so exposes these objects to potential
attackers. attackers.
skipping to change at page 10, line 23 skipping to change at page 9, line 17
Access to network resources varies depending on whether the resources Access to network resources varies depending on whether the resources
are in the same origin as the content attempting to access them. are in the same origin as the content attempting to access them.
Generally, reading information from another origin is forbidden. Generally, reading information from another origin is forbidden.
However, an origin is permitted to use some kinds of resources However, an origin is permitted to use some kinds of resources
retrieved from other origins. For example, an origin is permitted to retrieved from other origins. For example, an origin is permitted to
execute script, render images, and apply style sheets from any execute script, render images, and apply style sheets from any
origin. Likewise, an origin can display content from another origin, origin. Likewise, an origin can display content from another origin,
such as an HTML document in an HTML frame. Network resources can such as an HTML document in an HTML frame. Network resources can
also opt into letting other origins read their information, for also opt into letting other origins read their information, for
example using Cross-Origin Resource Sharing [CORS]. In these cases, example, using Cross-Origin Resource Sharing [CORS]. In these cases,
access is typically granted on a per-origin basis. access is typically granted on a per-origin basis.
Sending information to another origin is permitted. However, sending Sending information to another origin is permitted. However, sending
information over the network in arbitrary formats is dangerous. For information over the network in arbitrary formats is dangerous. For
this reason, user agents restrict documents to sending information this reason, user agents restrict documents to sending information
using particular protocols, such as in an HTTP request without custom using particular protocols, such as in an HTTP request without custom
headers. Expanding the set of allowed protocols, for example by headers. Expanding the set of allowed protocols, for example, by
adding support for WebSockets, must be done carefully to avoid adding support for WebSockets, must be done carefully to avoid
introducing vulnerabilities [WEBSOCKETS]. introducing vulnerabilities [RFC6455].
3.4.3. Pitfalls 3.4.3. Pitfalls
Whenever user agents allow one origin to interact with resources from Whenever user agents allow one origin to interact with resources from
another origin, they invite security issues. For example, the another origin, they invite security issues. For example, the
ability to display images from another origin leaks their height and ability to display images from another origin leaks their height and
width. Similarly, the ability to send network requests to another width. Similarly, the ability to send network requests to another
origin gives rise to cross-site request forgery vulnerabilities origin gives rise to cross-site request forgery vulnerabilities
[CSRF]. However, user agent implementors often balance these risks [CSRF]. However, user agent implementors often balance these risks
against the benefits of allowing the cross-origin interaction. For against the benefits of allowing the cross-origin interaction. For
skipping to change at page 12, line 10 skipping to change at page 10, line 23
access to objects and network resources within its own origin. This access to objects and network resources within its own origin. This
content is also granted limited access to objects and network content is also granted limited access to objects and network
resources of other origins, but these cross-origin privileges must be resources of other origins, but these cross-origin privileges must be
designed carefully to avoid security vulnerabilities. designed carefully to avoid security vulnerabilities.
4. Origin of a URI 4. Origin of a URI
The origin of a URI is the value computed by the following algorithm: The origin of a URI is the value computed by the following algorithm:
1. If the URI does not use a hierarchical element as a naming 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 authority (see [RFC3986], Section 3.2) or if the URI is not an
absolute URI, then generate a fresh globally unique identifier absolute URI, then generate a fresh globally unique identifier
and return that value. and return that value.
NOTE: Running this algorithm multiple times for the same URI NOTE: Running this algorithm multiple times for the same URI
can produce different values each time. Typically, user can produce different values each time. Typically, user
agents compute the origin of, for example, an HTML document agents compute the origin of, for example, an HTML document
once and use that origin for subsequent security checks rather once and use that origin for subsequent security checks rather
than recomputing the origin for each security check. than recomputing the origin for each security check.
2. Let uri-scheme be the scheme component of the URI, converted to 2. Let uri-scheme be the scheme component of the URI, converted to
lowercase. lowercase.
3. If the implementation doesn't support the protocol given by uri- 3. If the implementation doesn't support the protocol given by uri-
scheme, then return generate a fresh globally unique identifier scheme, then generate a fresh globally unique identifier and
and return that value. return that value.
4. If uri-scheme is "file", the implementation MAY return an 4. If uri-scheme is "file", the implementation MAY return an
implementation-defined value. implementation-defined value.
1. NOTE: Historically, user agents have granted content from the NOTE: Historically, user agents have granted content from the
file scheme a tremendous amount of privilege. However, file scheme a tremendous amount of privilege. However,
granting all local files such wide privileges can lead to granting all local files such wide privileges can lead to
privilege escalation attacks. Some user agents have had privilege escalation attacks. Some user agents have had
success granting local files directory-based privileges, but success granting local files directory-based privileges, but
this approach has not been widely adopted. Other user agents this approach has not been widely adopted. Other user agents
use globally unique identifiers for each file URI, which is use globally unique identifiers for each file URI, which is
the most secure option. the most secure option.
5. Let uri-host be the host component of the URI, converted to lower 5. Let uri-host be the host component of the URI, converted to lower
case (using the i;ascii-casemap collation defined in [RFC4790]). case (using the i;ascii-casemap collation defined in [RFC4790]).
1. NOTE: This document assumes that the user agent performs IDNA NOTE: This document assumes that the user agent performs
processing and validation when constructing the URI. In Internationalizing Domain Names in Applications (IDNA)
particular, this document assumes the uri-host will contain processing and validation when constructing the URI. In
only LDH-labels because the user agent will have already particular, this document assumes the uri-host will contain
converted any non-ASCII labels to their corresponding only LDH labels because the user agent will have already
A-labels (see [RFC5890]). For this reason, origin-based converted any non-ASCII labels to their corresponding A-labels
security policies are sensitive to the IDNA algorithm (see [RFC5890]). For this reason, origin-based security
employed by the user agent. See Section 8.4 for further policies are sensitive to the IDNA algorithm employed by the
discussion. user agent. See Section 8.4 for further discussion.
6. If there is no port component of the URI: 6. If there is no port component of the URI:
1. Let uri-port be the default port for the protocol given by 1. Let uri-port be the default port for the protocol given by
uri-scheme. uri-scheme.
Otherwise: Otherwise:
2. Let uri-port be the port component of the URI. 2. Let uri-port be the port component of the URI.
skipping to change at page 14, line 17 skipping to change at page 11, line 41
Two origins are "the same" if, and only if, they are identical. In Two origins are "the same" if, and only if, they are identical. In
particular: particular:
o If the two origins are scheme/host/port triples, the two origins o If the two origins are scheme/host/port triples, the two origins
are the same if, and only if, they have identical schemes, hosts, are the same if, and only if, they have identical schemes, hosts,
and ports. and ports.
o An origin that is a globally unique identifier cannot be the same o An origin that is a globally unique identifier cannot be the same
as an origin that is a scheme/host/port triple. as an origin that is a scheme/host/port triple.
Two URIs are the same-origin if their origins are the same. Two URIs are same-origin if their origins are the same.
NOTE: A URI is not necessarily same-origin with itself. For NOTE: A URI is not necessarily same-origin with itself. For
example, a data URI [RFC2397] is not same-origin with itself example, a data URI [RFC2397] is not same-origin with itself
because data URIs do not use a server-based naming authority and because data URIs do not use a server-based naming authority and
therefore have globally unique identifiers as origins. therefore have globally unique identifiers as origins.
6. Serializing Origins 6. Serializing Origins
This section defines how to serialize an origin to a unicode This section defines how to serialize an origin to a unicode
[Unicode52] string and to an ASCII [RFC20] string. [Unicode6] string and to an ASCII [RFC20] string.
6.1. Unicode Serialization of an Origin 6.1. Unicode Serialization of an Origin
The unicode-serialization of an origin is the value returned by the The unicode-serialization of an origin is the value returned by the
following algorithm: following algorithm:
1. If the origin is not a scheme/host/port triple, then return the 1. If the origin is not a scheme/host/port triple, then return the
string string
null null
skipping to change at page 15, line 31 skipping to change at page 12, line 26
and abort these steps. and abort these steps.
2. Otherwise, let result be the scheme part of the origin triple. 2. Otherwise, let result be the scheme part of the origin triple.
3. Append the string "://" to result. 3. Append the string "://" to result.
4. Append each component of the host part of the origin triple 4. Append each component of the host part of the origin triple
(converted as follows) to the result, separated by U+002E FULL (converted as follows) to the result, separated by U+002E FULL
STOP code points ("."): STOP code points ("."):
* If the component is an A-label, use the corresponding U-label 1. If the component is an A-label, use the corresponding U-label
instead (see [RFC5890] and [RFC5891]). instead (see [RFC5890] and [RFC5891]).
* Otherwise, use the component verbatim. 2. Otherwise, use the component verbatim.
5. If the port part of the origin triple is different than the 5. If the port part of the origin triple is different from the
default port for the protocol given by the scheme part of the default port for the protocol given by the scheme part of the
origin triple: origin triple:
1. Append a U+003A COLON code point (":") and the given port, in 1. Append a U+003A COLON code point (":") and the given port, in
base ten, to result. base ten, to result.
6. Return result. 6. Return result.
6.2. ASCII Serialization of an Origin 6.2. ASCII Serialization of an Origin
skipping to change at page 16, line 15 skipping to change at page 13, line 11
(i.e., the code point sequence U+006E, U+0075, U+006C, U+006C) (i.e., the code point sequence U+006E, U+0075, U+006C, U+006C)
and abort these steps. and abort these steps.
2. Otherwise, let result be the scheme part of the origin triple. 2. Otherwise, let result be the scheme part of the origin triple.
3. Append the string "://" to result. 3. Append the string "://" to result.
4. Append the host part of the origin triple to result. 4. Append the host part of the origin triple to result.
5. If the port part of the origin triple is different than the 5. If the port part of the origin triple is different from the
default port for the protocol given by the scheme part of the default port for the protocol given by the scheme part of the
origin triple: origin triple:
1. Append a U+003A COLON code points (":") and the given port, 1. Append a U+003A COLON code point (":") and the given port, in
in base ten, to result. base ten, to result.
6. Return result. 6. Return result.
7. The HTTP Origin header field 7. The HTTP Origin Header Field
This section defines the HTTP Origin header field. This section defines the HTTP Origin header field.
7.1. Syntax 7.1. Syntax
The Origin header field has the following syntax: The Origin header field has the following syntax:
origin = "Origin:" OWS origin-list-or-null OWS origin = "Origin:" OWS origin-list-or-null OWS
origin-list-or-null = %x6E %x75 %x6C %x6C / origin-list origin-list-or-null = %x6E %x75 %x6C %x6C / origin-list
origin-list = serialized-origin *( SP serialized-origin ) origin-list = serialized-origin *( SP serialized-origin )
serialized-origin = scheme "://" host [ ":" port ] serialized-origin = scheme "://" host [ ":" port ]
; <scheme>, <host>, <port> from RFC3986 ; <scheme>, <host>, <port> from RFC 3986
7.2. Semantics 7.2. Semantics
When included in an HTTP request, the Origin header field indicates When included in an HTTP request, the Origin header field indicates
the origin(s) that "caused" the user agent to issue the request, as 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 defined by the API that triggered the user agent to issue the
request. request.
For example, consider a user agent that executes scripts on behalf of 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 origins. If one of those scripts causes the user agent to issue an
skipping to change at page 19, line 35 skipping to change at page 15, line 20
partially or fully compromised, the same-origin policy might fail to partially or fully compromised, the same-origin policy might fail to
provide the security properties required by applications. provide the security properties required by applications.
Some URI schemes, such as https, are more resistant to DNS compromise Some URI schemes, such as https, are more resistant to DNS compromise
because user agents employ other mechanisms, such as certificates, to because user agents employ other mechanisms, such as certificates, to
verify the source of content retrieved from these URIs. Other URI verify the source of content retrieved from these URIs. Other URI
schemes, such as the chrome-extension URI scheme (see Section 4.3 of 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 [CRX]), use a public-key-based naming authority and are fully secure
against DNS compromise. against DNS compromise.
That the web origin concept isolates content retrieved from different The web origin concept isolates content retrieved from different URI
URI schemes is essential to containing the effects of DNS compromise. schemes; this is essential to containing the effects of DNS
compromise.
8.2. Divergent Units of Isolation 8.2. Divergent Units of Isolation
Over time, a number of technologies have converged on the web origin Over time, a number of technologies have converged on the web origin
concept as a convenient unit of isolation. However, many concept as a convenient unit of isolation. However, many
technologies in use today, such as cookies [RFC6265], pre-date the technologies in use today, such as cookies [RFC6265], pre-date the
modern web origin concept. These technologies often have different modern web origin concept. These technologies often have different
isolation units, leading to vulnerabilities. isolation units, leading to vulnerabilities.
One alternative is to use only the "registry-controlled" domain One alternative is to use only the "registry-controlled" domain
rather than the fully qualified domain name as the unit of isolation rather than the fully qualified domain name as the unit of isolation
(e.g., "example.com" instead of "www.example.com"). This practice is (e.g., "example.com" instead of "www.example.com"). This practice is
problematic for a number of reasons, and is NOT RECOMMENDED: problematic for a number of reasons and is NOT RECOMMENDED:
1. The notion of a "registry-controlled" domain is a function of 1. The notion of a "registry-controlled" domain is a function of
human practice surrounding the DNS rather than a property of the human practice surrounding the DNS rather than a property of the
DNS itself. For example, many municipalities in Japan run public DNS itself. For example, many municipalities in Japan run public
registries quite deep in the DNS hierarchy. There are widely registries quite deep in the DNS hierarchy. There are widely
used "public suffix lists", but these lists are difficult to keep used "public suffix lists", but these lists are difficult to keep
up to date and vary between implementations. up to date and vary between implementations.
2. This practice is incompatible with URI schemes that do not use a 2. This practice is incompatible with URI schemes that do not use a
DNS-based naming authority. For example, if a given URI scheme DNS-based naming authority. For example, if a given URI scheme
uses public keys as naming authorities, the notion of a uses public keys as naming authorities, the notion of a
"registry-controlled" public key is somewhat incoherent. Worse, "registry-controlled" public key is somewhat incoherent. Worse,
some URI schemes, such as nntp, used dotted delegation in the some URI schemes, such as nntp, use dotted delegation in the
opposite direction from DNS (e.g., alt.usenet.kooks) and others opposite direction from DNS (e.g., alt.usenet.kooks), and others
use the DNS, but present the labels in the reverse of the usual use the DNS but present the labels in the reverse of the usual
order (e.g., com.example.www). order (e.g., com.example.www).
At best, using registry-controlled domains is URI-scheme- and At best, using "registry-controlled" domains is URI-scheme- and
implementation-specific. At worst, differences between URI schemes implementation-specific. At worst, differences between URI schemes
and implementations can lead to vulnerabilities. and implementations can lead to vulnerabilities.
8.3. Ambient Authority 8.3. Ambient Authority
When using the same-origin policy, user agents grant authority to When using the same-origin policy, user agents grant authority to
content based on its URI rather than based which objects the content content based on its URI rather than based on which objects the
can designate. This disentangling of designation from authority is content can designate. This disentangling of designation from
an example of ambient authority and can lead to vulnerabilities. authority is an example of ambient authority and can lead to
vulnerabilities.
Consider, for example, cross-site scripting in HTML documents. If an Consider, for example, cross-site scripting in HTML documents. If an
attacker can inject script content into an HTML document, those attacker can inject script content into an HTML document, those
scripts will run with the authority of the document's origin, perhaps scripts will run with the authority of the document's origin, perhaps
allowing the script access to sensitive information, such as the allowing the script access to sensitive information, such as the
user's medical records. If, however, the script's authority were user's medical records. If, however, the script's authority were
limited to those objects that the script could designate, the limited to those objects that the script could designate, the
attacker would not gain any advantage by injecting the script into an attacker would not gain any advantage by injecting the script into an
HTML document hosted by a third party. HTML document hosted by a third party.
8.4. IDNA dependency and migration 8.4. IDNA Dependency and Migration
The security properties of the same-origin policy can depend The security properties of the same-origin policy can depend
crucially on details of the IDNA algorithm employed by the user crucially on details of the IDNA algorithm employed by the user
agent. In particular, a user agent might map some international agent. In particular, a user agent might map some international
domain names (for example, those involving the U+00DF character) to domain names (for example, those involving the U+00DF character) to
different ASCII representations depending on whether the user agent different ASCII representations depending on whether the user agent
uses IDNA2003 [RFC3490] or IDNA2008 [RFC5890]. uses IDNA2003 [RFC3490] or IDNA2008 [RFC5890].
Migrating from one IDNA algorithm to another might redraw a number of Migrating from one IDNA algorithm to another might redraw a number of
security boundaries, potentially erecting new security boundaries or, security boundaries, potentially erecting new security boundaries or,
worse, tearing down security boundaries between two mutually worse, tearing down security boundaries between two mutually
distrusting entities. Changing security boundaries is risky because distrusting entities. Changing security boundaries is risky because
combining two mutually distrusting entities into the same origin combining two mutually distrusting entities into the same origin
might allow one to attack the other. might allow one to attack the other.
9. IANA Considerations 9. IANA Considerations
The permanent message header field registry (see [RFC3864]) should be The permanent message header field registry (see [RFC3864]) has been
updated with the following registrations: updated with the following registration:
9.1. Origin
Header field name: Origin Header field name: Origin
Applicable protocol: http Applicable protocol: http
Status: standard Status: standard
Author/Change controller: IETF Author/Change controller: IETF
Specification document: this specification (Section 7) Specification document: this specification (Section 7)
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC20] Cerf, V., "ASCII format for network interchange", RFC 20, [RFC20] Cerf, V., "ASCII format for network interchange", RFC 20,
October 1969. October 1969.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004. September 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet [RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet
Application Protocol Collation Registry", RFC 4790, Application Protocol Collation Registry", RFC 4790,
March 2007. March 2007.
[Unicode52] [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
The Unicode Consortium, "The Unicode Standard, Version Syntax Specifications: ABNF", STD 68, RFC 5234,
5.1.0", Unicode 5.0.0, Boston, MA, Addison-Wesley ISBN January 2008.
0-321-48091-0, as amended by Unicode 5.1.0
http://www.unicode.org/versions/Unicode5.1.0/, 2008,
<http://www.unicode.org/versions/Unicode5.2.0/>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5890] Klensin, J., "Internationalized Domain Names for
Specifications: ABNF", STD 68, RFC 5234, January 2008. Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010.
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5891] Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Protocol", RFC 5891, August 2010.
RFC 5890, August 2010.
[RFC5891] Klensin, J., "Internationalized Domain Names in [Unicode6] The Unicode Consortium, "The Unicode Standard, Version
Applications (IDNA): Protocol", RFC 5891, August 2010. 6.0.0", 2011,
<http://www.unicode.org/versions/Unicode6.0.0/>.
10.2. Informative References 10.2. Informative References
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [BOFGO] Jackson, C. and A. Barth, "Beware of Finer-Grained
(TLS) Protocol Version 1.2", RFC 5246, August 2008. Origins", 2008,
<http://w2spconf.com/2008/papers/s2p1.pdf>.
[RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397,
August 1998.
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within [CORS] van Kesteren, A., "Cross-Origin Resource Sharing", W3C
HTTP/1.1", RFC 2817, May 2000. Working Draft WD-cors-20100727, July 2010,
<http://www.w3.org/TR/2010/WD-cors-20100727/>.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, Latest version available at <http://www.w3.org/TR/cors/>.
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
See Section 8.4 for an explanation why the normative [CRX] Barth, A., Felt, A., Saxena, P., and A. Boodman,
reference to an obsoleted specification is needed. "Protecting Browsers from Extension Vulnerabilities",
2010, <http://www.isoc.org/isoc/conferences/ndss/10/pdf/
04.pdf>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [CSRF] Barth, A., Jackson, C., and J. Mitchell, "Robust Defenses
April 2011. for Cross-Site Request Forgery", 2008,
<http://portal.acm.org/citation.cfm?id=1455770.1455782>.
[WEBSOCKETS] [HTML] Hickson, I., "HTML5", W3C Working Draft WD-html5-
Fette, I. and A. Melnikov, "The WebSocket protocol", 20110525, May 2011,
draft-ietf-hybi-thewebsocketprotocol-17 (work in <http://www.w3.org/TR/2011/WD-html5-20110525/>.
progress), September 2011.
[SNIFF] Barth, A. and I. Hickson, "Media Type Sniffing", Latest version available at
draft-ietf-websec-mime-sniff-03 (work in progress), <http://www.w3.org/TR/html5/>.
May 2011.
[HTML] Hickson, I., "HTML5", W3C Working Draft WD-html5-20110525, [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397,
May 2011, <http://www.w3.org/TR/2011/WD-html5-20110525/>. August 1998.
Latest version available at <http://www.w3.org/TR/html5/>. [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
HTTP/1.1", RFC 2817, May 2000.
[CORS] van Kesteren, A., "Cross-Origin Resource Sharing", W3C [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
Working Draft WD-cors-20100727, July 2010, "Internationalizing Domain Names in Applications (IDNA)",
<http://www.w3.org/TR/2010/WD-cors-20100727/>. RFC 3490, March 2003.
Latest version available at <http://www.w3.org/TR/cors/>. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[CSRF] Barth, A., Jackson, C., and J. Mitchell, "Robust Defenses [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
for Cross-Site Request Forgery", 2008, April 2011.
<http://portal.acm.org/citation.cfm?id=1455770.1455782>.
[BOFGO] Jackson, C. and A. Barth, "Beware of Finer-Grained [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol",
Origins", 2008, RFC 6455, December 2011.
<http://w2spconf.com/2008/papers/s2p1.pdf>.
[CRX] Barth, A., Felt, A., Saxena, P., and A. Boodman, [SNIFF] Barth, A. and I. Hickson, "Media Type Sniffing", Work
"Protecting Browsers from Extension Vulnerabilities", in Progress, May 2011.
2010,
<http://www.isoc.org/isoc/conferences/ndss/10/pdf/04.pdf>.
Appendix A. Acknowledgements Appendix A. Acknowledgements
We would like to thank Lucas Adamski, Stephen Farrell, Miguel A. We would like to thank Lucas Adamski, Stephen Farrell, Miguel A.
Garcia, Tobias Gondrom, Ian Hickson, Anne van Kesteren, Jeff Hodges, Garcia, Tobias Gondrom, Ian Hickson, Anne van Kesteren, Jeff Hodges,
Collin Jackson, Larry Masinter, Alexey Melnikov, Mark Nottingham, Collin Jackson, Larry Masinter, Alexey Melnikov, Mark Nottingham,
Julian Reschke, Peter Saint-Andre, Jonas Sicking, Sid Stamm, Daniel Julian Reschke, Peter Saint-Andre, Jonas Sicking, Sid Stamm, Daniel
Veditz, and Chris Weber for their valuable feedback on this document. Veditz, and Chris Weber for their valuable feedback on this document.
Author's Address Author's Address
Adam Barth Adam Barth
Google, Inc. Google, Inc.
Email: ietf@adambarth.com EMail: ietf@adambarth.com
URI: http://www.adambarth.com/ URI: http://www.adambarth.com/
 End of changes. 69 change blocks. 
197 lines changed or deleted 185 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/