idnits 2.17.1 draft-ietf-websec-origin-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (October 3, 2011) is 4551 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode52' -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 3490 (Obsoleted by RFC 5890, RFC 5891) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 websec A. Barth 3 Internet-Draft Google, Inc. 4 Intended status: Standards Track October 3, 2011 5 Expires: April 5, 2012 7 The Web Origin Concept 8 draft-ietf-websec-origin-06 10 Abstract 12 This document defines the concept of an "origin", which is often used 13 as the scope of authority or privilege by user agents. Typically, 14 user agents isolate content retrieved from different origins to 15 prevent malicious web site operators from interfering with the 16 operation of benign web sites. In addition to outlining the 17 principles that underlie the concept of origin, this document defines 18 how to determine the origin of a URI, how to serialize an origin into 19 a string, and an HTTP header field, named "Origin", that indicates 20 which origins are associated with an HTTP request. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 5, 2012. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . . 4 59 2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 60 2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. Principles of the Same-Origin Policy . . . . . . . . . . . . . 6 62 3.1. Trust . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.1.1. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . 7 64 3.2. Origin . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 3.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 8 66 3.3. Authority . . . . . . . . . . . . . . . . . . . . . . . . 8 67 3.3.1. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . 9 68 3.4. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 3.4.1. Object Access . . . . . . . . . . . . . . . . . . . . 9 70 3.4.2. Network Access . . . . . . . . . . . . . . . . . . . . 10 71 3.4.3. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . 10 72 3.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 11 73 4. Origin of a URI . . . . . . . . . . . . . . . . . . . . . . . 12 74 5. Comparing Origins . . . . . . . . . . . . . . . . . . . . . . 14 75 6. Serializing Origins . . . . . . . . . . . . . . . . . . . . . 15 76 6.1. Unicode Serialization of an Origin . . . . . . . . . . . . 15 77 6.2. ASCII Serialization of an Origin . . . . . . . . . . . . . 15 78 7. The HTTP Origin header field . . . . . . . . . . . . . . . . . 17 79 7.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 7.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 17 81 7.3. User Agent Requirements . . . . . . . . . . . . . . . . . 17 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 83 8.1. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 19 84 8.2. Divergent Units of Isolation . . . . . . . . . . . . . . . 19 85 8.3. Ambient Authority . . . . . . . . . . . . . . . . . . . . 20 86 8.4. IDNA dependency and migration . . . . . . . . . . . . . . 20 87 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 88 9.1. Origin . . . . . . . . . . . . . . . . . . . . . . . . . . 22 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 90 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 91 10.2. Informative References . . . . . . . . . . . . . . . . . . 23 92 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25 93 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26 95 1. Introduction 97 User agents interact with content created by a large number of 98 authors. Although many of those authors are well-meaning, some 99 authors might be malicious. To the extent that user agents undertake 100 actions based on content they process, user agent implementors might 101 wish to restrict the ability of malicious authors to disrupt the 102 confidentiality or integrity of other content or servers. 104 As an example, consider an HTTP user agent that renders HTML content 105 retrieved from various servers. If the user agent executes scripts 106 contained in those documents, the user agent implementor might wish 107 to prevent scripts retrieved from a malicious server from reading 108 documents stored on an honest server, which might, for example, be 109 behind a firewall. 111 Traditionally, user agents have divided content according to its 112 "origin". More specifically, user agents allow content retrieved 113 from one origin to interact freely with other content retrieved from 114 that origin, but user agents restrict how that content can interact 115 with content from another origin. 117 This document describes the principles behind the so-called same- 118 origin policy as well as the "nuts and bolts" of comparing and 119 serializing origins. This document does not describe all the facets 120 of the same-origin policy, the details of which are left to other 121 specifications, such as HTML [HTML] and WebSockets [WEBSOCKETS], 122 because the details are often application-specific. 124 2. Conventions 126 2.1. Conformance Criteria 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [RFC2119]. 132 Requirements phrased in the imperative as part of algorithms (such as 133 "strip any leading space characters" or "return false and abort these 134 steps") are to be interpreted with the meaning of the key word 135 ("MUST", "SHOULD", "MAY", etc) used in introducing the algorithm. 137 Conformance requirements phrased as algorithms or specific steps can 138 be implemented in any manner, so long as the end result is 139 equivalent. In particular, the algorithms defined in this 140 specification are intended to be easy to understand and are not 141 intended to be performant. 143 2.2. Syntax Notation 145 This specification uses the Augmented Backus-Naur Form (ABNF) 146 notation of [RFC5234]. 148 The following core rules are included by reference, as defined in 149 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 150 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 151 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit 152 sequence of data), SP (space), HTAB (horizontal tab), CHAR (any US- 153 ASCII character), VCHAR (any visible US-ASCII character), and WSP 154 (whitespace). 156 The OWS rule is used where zero or more linear whitespace octets 157 might appear. OWS SHOULD either not be produced or be produced as a 158 single SP. Multiple OWS octets that occur within field-content 159 SHOULD either be replaced with a single SP or transformed to all SP 160 octets (each octet other than SP replaced with SP) before 161 interpreting the field value or forwarding the message downstream. 163 OWS = *( SP / HTAB / obs-fold ) 164 ; "optional" whitespace 165 obs-fold = CRLF ( SP / HTAB ) 166 ; obsolete line folding 168 2.3. Terminology 170 The terms user agent, client, server, proxy, and origin server have 171 the same meaning as in the HTTP/1.1 specification ([RFC2616], Section 172 1.3). 174 A globally unique identifier is a value which is different from all 175 other previously existing values. For example, a sufficiently long 176 random string is likely to be a globally unique identifier. If the 177 origin value never leaves the user agent, a monotonically increasing 178 counter local to the user agent can also serve as a globally unique 179 identifier 181 3. Principles of the Same-Origin Policy 183 Many user agents undertake actions on behalf of remote parties. For 184 example, HTTP user agents follow redirects, which are instructions 185 from remote servers and HTML user agents expose rich DOM interfaces 186 to scripts retrieved from remote servers. 188 Without any security model, user agents might undertake actions 189 detrimental to the user or to other parties. Over time, many web- 190 related technologies have converged towards a common security model, 191 known colloquially as the "same-origin policy". Although this 192 security model evolved largely organically, the same-origin policy 193 can be understood in terms of a handful of key concepts. This 194 section presents those concepts and provides advice about how to use 195 these concepts securely. 197 3.1. Trust 199 The same-origin policy specifies trust by URI. For example, HTML 200 documents designate which script to run with a URI: 202 204 When a user agent processes this element, the user agent will fetch 205 the script at the designated URI and execute the script with the 206 privileges of the document. In this way, the document grants all the 207 privileges it has to the resource designated by the URI. In essence, 208 the document declares that it trusts the integrity of information 209 retrieved from that URI. 211 In addition to importing libraries from URIs, user agents also send 212 information to remote parties designated by URI. For example, 213 consider the HTML form element: 215
216 ... ... 217
219 When the user enters his or her password and submits the form, the 220 user agent sends the password to the network endpoint designated by 221 the URI. In this way, the document exports its secret data to that 222 URI, in essence declaring that it trusts the confidentiality of 223 information sent to that URI. 225 3.1.1. Pitfalls 227 When designing new protocols that use the same-origin policy, make 228 sure that important trust distinctions are visible in URIs. For 229 example, if both TLS and non-TLS protected resources used the "http" 230 URI scheme (as in [RFC2817]), a document would be unable to specify 231 that it wished to retrieve a script only over TLS. By using the 232 "https" URI scheme, documents are able to indicate that they wish to 233 interact with resources that are protected from active network 234 attackers. 236 3.2. Origin 238 In principle, user agents could treat every URI as a separate 239 protection domain and require explicit consent for content retrieved 240 from one URI to interact with another URI. Unfortunately, this 241 design is cumbersome for developers because web applications often 242 consist of a number of resources acting in concert. 244 Instead, user agents group URIs together into protection domains 245 called "origins". Roughly speaking, two URIs are part of the same 246 origin (i.e., represent the same principal) if they have the same 247 scheme, host, and port. (See Section 4 for full details.) 249 Q: Why not just use the host? 251 A: Including the scheme in the origin tuple is essential for 252 security. If user agents did not include the scheme, there would be 253 no isolation between http://example.com and https://example.com 254 because the two have the same host. However, without this isolation, 255 an active network attacker could corrupt content retrieved from 256 http://example.com and have that content instruct the user agent to 257 compromise the confidentiality and integrity of content retrieved 258 from https://example.com, bypassing the protections afforded by TLS 259 [RFC5246]. 261 Q: Why use the fully qualified host name instead of just the "top- 262 level" domain? 264 A: Although the DNS has hierarchical delegation, the trust 265 relationships between host names vary by deployment. For example, at 266 many educational institutions, students can host content at 267 https://example.edu/~student/, but that does not mean a document 268 authored by a student should be part of the same origin (i.e., 269 inhabit the same protection domain) as a web application for managing 270 grades hosted at https://grades.example.edu/. 272 The example.edu deployment illustrates that grouping resources by 273 origin does not always align perfectly with every deployment 274 scenario. In this deployment every student's web site inhabits the 275 same origin, which might not be desirable. In some sense, the origin 276 granularity is a historical artifact of how the security model 277 evolved. 279 3.2.1. Examples 281 All of the following resources have the same origin: 283 http://example.com/ 284 http://example.com:80/ 285 http://example.com/path/file 287 Each of the URIs has the same scheme, host, and port components. 289 Each of the following resources has a different origin from the 290 others. 292 http://example.com/ 293 http://example.com:8080/ 294 http://www.example.com/ 295 https://example.com:80/ 296 https://example.com/ 297 http://example.org/ 298 http://ietf.org/ 300 In each case, at least one of the scheme, host, and port component 301 will differ from the others in the list. 303 3.3. Authority 305 Although user agents group URIs into origins, not every resource in 306 an origin carries the same authority (in the security sense of the 307 word "authority", not in the [RFC3986] sense). For example, an image 308 is passive content and, therefore, carries no authority, meaning the 309 image has no access to the objects and resources available to its 310 origin. By contrast, an HTML document carries the full authority of 311 its origin and scripts within (or imported into) the document can 312 access every resource in its origin. 314 User agents determine how much authority to grant a resource by 315 examining its media type. For example, resources with a media type 316 of image/png are treated as images and resources with a media type of 317 text/html are treated as HTML documents. 319 When hosting untrusted content (such as user-generated content), web 320 applications can limit that content's authority by restricting its 321 media type. For example, serving user-generated content as image/png 322 is less risky than serving user-generated content as text/html. Of 323 course many web applications incorporate untrusted content in their 324 HTML documents. If not done carefully, these applications risk 325 leaking their origin's authority to the untrusted content, a 326 vulnerability commonly known as cross-site scripting. 328 3.3.1. Pitfalls 330 When designing new pieces of the web platform, be careful not to 331 grant authority to resources irrespective of media type. Many web 332 applications serve untrusted content with restricted media types. A 333 new web platform feature that grants authority to these pieces of 334 content risks introducing vulnerabilities into existing applications. 335 Instead, prefer to grant authority to media types that already 336 possess the origin's full authority or to new media types designed 337 specifically to carry the new authority. 339 In order to remain compatible with servers that supply incorrect 340 media types, some user agents employ "content sniffing" and treat 341 content as if it had a different media type than the media type 342 supplied by the server. If not done carefully, content sniffing can 343 lead to security vulnerabilities because user agents might grant low- 344 authority media types, such as images, the privileges of high- 345 authority media types, such as HTML documents [SNIFF]. 347 3.4. Policy 349 Generally speaking, user agents isolate different origins and permit 350 controlled communication between origins. The details of how user 351 agents provide isolation and communication vary depending on several 352 factors. 354 3.4.1. Object Access 356 Most objects (also known as application programming interfaces or 357 APIs) exposed by the user agent are available only to the same 358 origin. Specifically, content retrieved from one URI can access 359 objects associated with content retrieved from another URI if, and 360 only if, the two URIs belong to the same origin, e.g., have same 361 scheme, host, and port. 363 There are some exceptions to this general rule. For example, some 364 parts of HTML's Location interface are available across origins 365 (e.g., to allow for navigating other browsing contexts). As another 366 example, HTML's postMessage interface is visible across origins 367 explicitly to facilitate cross-origin communication. Exposing 368 objects to foreign origins is dangerous and should be done only with 369 great care because doing so exposes these objects to potential 370 attackers. 372 3.4.2. Network Access 374 Access to network resources varies depending on whether the resources 375 are in the same origin as the content attempting to access them. 377 Generally, reading information from another origin is forbidden. 378 However, an origin is permitted to use some kinds of resources 379 retrieved from other origins. For example, an origin is permitted to 380 execute script, render images, and apply style sheets from any 381 origin. Likewise, an origin can display content from another origin, 382 such as an HTML document in an HTML frame. Network resources can 383 also opt into letting other origins read their information, for 384 example using Cross-Origin Resource Sharing [CORS]. In these cases, 385 access is typically granted on a per-origin basis. 387 Sending information to another origin is permitted. However, sending 388 information over the network in arbitrary formats is dangerous. For 389 this reason, user agents restrict documents to sending information 390 using particular protocols, such as in an HTTP request without custom 391 headers. Expanding the set of allowed protocols, for example by 392 adding support for WebSockets, must be done carefully to avoid 393 introducing vulnerabilities [WEBSOCKETS]. 395 3.4.3. Pitfalls 397 Whenever user agents allow one origin to interact with resources from 398 another origin, they invite security issues. For example, the 399 ability to display images from another origin leaks their height and 400 width. Similarly, the ability to send network requests to another 401 origin gives rise to cross-site request forgery vulnerabilities 402 [CSRF]. However, user agent implementors often balance these risks 403 against the benefits of allowing the cross-origin interaction. For 404 example, an HTML user agent that blocked cross-origin network 405 requests would prevent its users from following hyperlinks, a core 406 feature of the web. 408 When adding new functionality to the web platform, it can be tempting 409 to grant a privilege to one resource but to withhold that privilege 410 from another resource in the same origin. However, withholding 411 privileges in this way is ineffective because the resource without 412 the privilege can usually obtain the privilege anyway because user 413 agents do not isolate resources within an origin. Instead, 414 privileges should be granted or withheld from origins as a whole 415 (rather than discriminating between individual resources within an 416 origin) [BOFGO]. 418 3.5. Conclusion 420 The same-origin policy uses URIs to designate trust relationships. 421 URIs are grouped together into origins, which represent protection 422 domains. Some resources in an origin (e.g., active content) are 423 granted the origin's full authority, whereas other resources in the 424 origin (e.g., passive content) are not granted the origin's 425 authority. Content that carries its origin's authority is granted 426 access to objects and network resources within its own origin. This 427 content is also granted limited access to objects and network 428 resources of other origins, but these cross-origin privileges must be 429 designed carefully to avoid security vulnerabilities. 431 4. Origin of a URI 433 The origin of a URI is the value computed by the following algorithm: 435 1. If the URI does not use a hierarchical element as a naming 436 authority (see [RFC3986], Section 3.2), or if the URI is not an 437 absolute URI, then generate a fresh globally unique identifier 438 and return that value. 440 NOTE: Running this algorithm multiple times for the same URI 441 can produce different values each time. Typically, user 442 agents compute the origin of, for example, an HTML document 443 once and use that origin for subsequent security checks rather 444 than recomputing the origin for each security check. 446 2. Let uri-scheme be the scheme component of the URI, converted to 447 lowercase. 449 3. If the implementation doesn't support the protocol given by uri- 450 scheme, then return generate a fresh globally unique identifier 451 and return that value. 453 4. If uri-scheme is "file", the implementation MAY return an 454 implementation-defined value. 456 1. NOTE: Historically, user agents have granted content from the 457 file scheme a tremendous amount of privilege. However, 458 granting all local files such wide privileges can lead to 459 privilege escalation attacks. Some user agents have had 460 success granting local files directory-based privileges, but 461 this approach has not been widely adopted. Other user agents 462 use globally unique identifiers for each file URI, which is 463 the most secure option. 465 5. Let uri-host be the host component of the URI, converted to lower 466 case (using the i;ascii-casemap collation defined in [RFC4790]). 468 1. NOTE: This document assumes that the user agent performs IDNA 469 processing and validation when constructing the URI. In 470 particular, this document assumes the uri-host will contain 471 only LDH-labels because the user agent will have already 472 converted any non-ASCII labels to their corresponding 473 A-labels (see [RFC5890]). For this reason, origin-based 474 security policies are sensitive to the IDNA algorithm 475 employed by the user agent. See Section 8.4 for further 476 discussion. 478 6. If there is no port component of the URI: 480 1. Let uri-port be the default port for the protocol given by 481 uri-scheme. 483 Otherwise: 485 2. Let uri-port be the port component of the URI. 487 7. Return the triple (uri-scheme, uri-host, uri-port). 489 5. Comparing Origins 491 Two origins are "the same" if, and only if, they are identical. In 492 particular: 494 o If the two origins are scheme/host/port triples, the two origins 495 are the same if, and only if, they have identical schemes, hosts, 496 and ports. 498 o An origin that is a globally unique identifier cannot be the same 499 as an origin that is a scheme/host/port triple. 501 Two URIs are the same-origin if their origins are the same. 503 NOTE: A URI is not necessarily same-origin with itself. For 504 example, a data URI [RFC2397] is not same-origin with itself 505 because data URIs do not use a server-based naming authority and 506 therefore have globally unique identifiers as origins. 508 6. Serializing Origins 510 This section defines how to serialize an origin to a unicode 511 [Unicode52] string and to an ASCII [RFC20] string. 513 6.1. Unicode Serialization of an Origin 515 The unicode-serialization of an origin is the value returned by the 516 following algorithm: 518 1. If the origin is not a scheme/host/port triple, then return the 519 string 521 null 523 (i.e., the code point sequence U+006E, U+0075, U+006C, U+006C) 524 and abort these steps. 526 2. Otherwise, let result be the scheme part of the origin triple. 528 3. Append the string "://" to result. 530 4. Append each component of the host part of the origin triple 531 (converted as follows) to the result, separated by U+002E FULL 532 STOP code points ("."): 534 * If the component is an A-label, use the corresponding U-label 535 instead (see [RFC5890] and [RFC5891]). 537 * Otherwise, use the component verbatim. 539 5. If the port part of the origin triple is different than the 540 default port for the protocol given by the scheme part of the 541 origin triple: 543 1. Append a U+003A COLON code point (":") and the given port, in 544 base ten, to result. 546 6. Return result. 548 6.2. ASCII Serialization of an Origin 550 The ascii-serialization of an origin is the value returned by the 551 following algorithm: 553 1. If the origin is not a scheme/host/port triple, then return the 554 string 555 null 557 (i.e., the code point sequence U+006E, U+0075, U+006C, U+006C) 558 and abort these steps. 560 2. Otherwise, let result be the scheme part of the origin triple. 562 3. Append the string "://" to result. 564 4. Append the host part of the origin triple to result. 566 5. If the port part of the origin triple is different than the 567 default port for the protocol given by the scheme part of the 568 origin triple: 570 1. Append a U+003A COLON code points (":") and the given port, 571 in base ten, to result. 573 6. Return result. 575 7. The HTTP Origin header field 577 This section defines the HTTP Origin header field. 579 7.1. Syntax 581 The Origin header field has the following syntax: 583 origin = "Origin:" OWS origin-list-or-null OWS 584 origin-list-or-null = %x6E %x75 %x6C %x6C / origin-list 585 origin-list = serialized-origin *( SP serialized-origin ) 586 serialized-origin = scheme "://" host [ ":" port ] 587 ; , , from RFC3986 589 7.2. Semantics 591 When included in an HTTP request, the Origin header field indicates 592 the origin(s) that "caused" the user agent to issue the request, as 593 defined by the API that triggered the user agent to issue the 594 request. 596 For example, consider a user agent that executes scripts on behalf of 597 origins. If one of those scripts causes the user agent to issue an 598 HTTP request, the user agent MAY use the Origin header field to 599 inform the server of the security context in which the script was 600 executing when it caused the user agent to issue the request. 602 In some cases, a number of origins contribute to causing the user 603 agents to issue an HTTP request. In those cases, the user agent MAY 604 list all the origins in the Origin header field. For example, if the 605 HTTP request was initially issued by one origin but then later 606 redirected by another origin, the user agent MAY inform the server 607 that two origins were involved in causing the user agent to issue the 608 request. 610 7.3. User Agent Requirements 612 The user agent MAY include an Origin header field in any HTTP 613 request. 615 The user agent MUST NOT include more than one Origin header field in 616 any HTTP request. 618 Whenever a user agent issues an HTTP request from a "privacy- 619 sensitive" context, the user agent MUST send the value "null" in the 620 Origin header field. 622 NOTE: This document does not define the notion of a privacy- 623 sensitive context. Applications that generate HTTP requests can 624 designate contexts as privacy-sensitive to impose restrictions on 625 how user agents generate Origin header fields. 627 When generating an Origin header field, the user agent MUST meet the 628 following requirements: 630 o Each of the serialized-origin productions in the grammar MUST be 631 the ascii-serialization of an origin. 633 o No two consecutive serialized-origin productions in the grammar 634 can be identical. In particular, if the user agent would generate 635 two consecutive serialized-origins, the user agent MUST NOT 636 generate the second one. 638 8. Security Considerations 640 The same-origin policy is one of the cornerstones of security for 641 many user agents, including web browsers. Historically, some user 642 agents tried other security models, including taint tracking and 643 exfiltration prevention, but those models proved difficult to 644 implement at the time (although there has been recent interest in 645 reviving some of these ideas). 647 Evaluating the security of the same-origin policy is difficult 648 because the origin concept itself plays such a central role in the 649 security landscape. The notional origin itself is just a unit of 650 isolation, imperfect as are most one-size-fits-all notions. That 651 said, there are some systemic weaknesses, discussed below. 653 8.1. Reliance on DNS 655 In practice, the same-origin policy relies upon the Domain Name 656 System (DNS) for security because many commonly used URI schemes, 657 such as http, use DNS-based naming authorities. If the DNS is 658 partially or fully compromised, the same-origin policy might fail to 659 provide the security properties required by applications. 661 Some URI schemes, such as https, are more resistant to DNS compromise 662 because user agents employ other mechanisms, such as certificates, to 663 verify the source of content retrieved from these URIs. Other URI 664 schemes, such as the chrome-extension URI scheme (see Section 4.3 of 665 [CRX]), use a public-key-based naming authority and are fully secure 666 against DNS compromise. 668 That the web origin concept isolates content retrieved from different 669 URI schemes is essential to containing the effects of DNS compromise. 671 8.2. Divergent Units of Isolation 673 Over time, a number of technologies have converged on the web origin 674 concept as a convenient unit of isolation. However, many 675 technologies in use today, such as cookies [RFC6265], pre-date the 676 modern web origin concept. These technologies often have different 677 isolation units, leading to vulnerabilities. 679 One alternative is to use only the "registry-controlled" domain 680 rather than the fully qualified domain name as the unit of isolation 681 (e.g., "example.com" instead of "www.example.com"). This practice is 682 problematic for a number of reasons, and is NOT RECOMMENDED: 684 1. The notion of a "registry-controlled" domain is a function of 685 human practice surrounding the DNS rather than a property of the 686 DNS itself. For example, many municipalities in Japan run public 687 registries quite deep in the DNS hierarchy. There are widely 688 used "public suffix lists", but these lists are difficult to keep 689 up to date and vary between implementations. 691 2. This practice is incompatible with URI schemes that do not use a 692 DNS-based naming authority. For example, if a given URI scheme 693 uses public keys as naming authorities, the notion of a 694 "registry-controlled" public key is somewhat incoherent. Worse, 695 some URI schemes, such as nntp, used dotted delegation in the 696 opposite direction from DNS (e.g., alt.usenet.kooks) and others 697 use the DNS, but present the labels in the reverse of the usual 698 order (e.g., com.example.www). 700 At best, using registry-controlled domains is URI-scheme- and 701 implementation-specific. At worst, differences between URI schemes 702 and implementations can lead to vulnerabilities. 704 8.3. Ambient Authority 706 When using the same-origin policy, user agents grant authority to 707 content based on its URI rather than based which objects the content 708 can designate. This disentangling of designation from authority is 709 an example of ambient authority and can lead to vulnerabilities. 711 Consider, for example, cross-site scripting in HTML documents. If an 712 attacker can inject script content into an HTML document, those 713 scripts will run with the authority of the document's origin, perhaps 714 allowing the script access to sensitive information, such as the 715 user's medical records. If, however, the script's authority were 716 limited to those objects that the script could designate, the 717 attacker would not gain any advantage by injecting the script into an 718 HTML document hosted by a third party. 720 8.4. IDNA dependency and migration 722 The security properties of the same-origin policy can depend 723 crucially on details of the IDNA algorithm employed by the user 724 agent. In particular, a user agent might map some international 725 domain names (for example, those involving the U+00DF character) to 726 different ASCII representations depending on whether the user agent 727 uses IDNA2003 [RFC3490] or IDNA2008 [RFC5890]. 729 Migrating from one IDNA algorithm to another might redraw a number of 730 security boundaries, potentially erecting new security boundaries or, 731 worse, tearing down security boundaries between two mutually 732 distrusting entities. Changing security boundaries is risky because 733 combining two mutually distrusting entities into the same origin 734 might allow one to attack the other. 736 9. IANA Considerations 738 The permanent message header field registry (see [RFC3864]) should be 739 updated with the following registrations: 741 9.1. Origin 743 Header field name: Origin 745 Applicable protocol: http 747 Status: standard 749 Author/Change controller: IETF 751 Specification document: this specification (Section 7) 753 10. References 755 10.1. Normative References 757 [RFC20] Cerf, V., "ASCII format for network interchange", RFC 20, 758 October 1969. 760 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 761 Requirement Levels", BCP 14, RFC 2119, March 1997. 763 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 764 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 765 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 767 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 768 Procedures for Message Header Fields", BCP 90, RFC 3864, 769 September 2004. 771 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 772 Resource Identifier (URI): Generic Syntax", STD 66, 773 RFC 3986, January 2005. 775 [RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet 776 Application Protocol Collation Registry", RFC 4790, 777 March 2007. 779 [Unicode52] 780 The Unicode Consortium, "The Unicode Standard, Version 781 5.1.0", Unicode 5.0.0, Boston, MA, Addison-Wesley ISBN 782 0-321-48091-0, as amended by Unicode 5.1.0 783 http://www.unicode.org/versions/Unicode5.1.0/, 2008, 784 . 786 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 787 Specifications: ABNF", STD 68, RFC 5234, January 2008. 789 [RFC5890] Klensin, J., "Internationalized Domain Names for 790 Applications (IDNA): Definitions and Document Framework", 791 RFC 5890, August 2010. 793 [RFC5891] Klensin, J., "Internationalized Domain Names in 794 Applications (IDNA): Protocol", RFC 5891, August 2010. 796 10.2. Informative References 798 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 799 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 801 [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, 802 August 1998. 804 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 805 HTTP/1.1", RFC 2817, May 2000. 807 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 808 "Internationalizing Domain Names in Applications (IDNA)", 809 RFC 3490, March 2003. 811 See Section 8.4 for an explanation why the normative 812 reference to an obsoleted specification is needed. 814 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 815 April 2011. 817 [WEBSOCKETS] 818 Fette, I. and A. Melnikov, "The WebSocket protocol", 819 draft-ietf-hybi-thewebsocketprotocol-17 (work in 820 progress), September 2011. 822 [SNIFF] Barth, A. and I. Hickson, "Media Type Sniffing", 823 draft-ietf-websec-mime-sniff-03 (work in progress), 824 May 2011. 826 [HTML] Hickson, I., "HTML5", W3C Working Draft WD-html5-20110525, 827 May 2011, . 829 Latest version available at . 831 [CORS] van Kesteren, A., "Cross-Origin Resource Sharing", W3C 832 Working Draft WD-cors-20100727, July 2010, 833 . 835 Latest version available at . 837 [CSRF] Barth, A., Jackson, C., and J. Mitchell, "Robust Defenses 838 for Cross-Site Request Forgery", 2008, 839 . 841 [BOFGO] Jackson, C. and A. Barth, "Beware of Finer-Grained 842 Origins", 2008, 843 . 845 [CRX] Barth, A., Felt, A., Saxena, P., and A. Boodman, 846 "Protecting Browsers from Extension Vulnerabilities", 847 2010, 848 . 850 Appendix A. Acknowledgements 852 We would like to thank Lucas Adamski, Stephen Farrell, Miguel A. 853 Garcia, Tobias Gondrom, Ian Hickson, Anne van Kesteren, Jeff Hodges, 854 Collin Jackson, Larry Masinter, Alexey Melnikov, Mark Nottingham, 855 Julian Reschke, Peter Saint-Andre, Jonas Sicking, Sid Stamm, Daniel 856 Veditz, and Chris Weber for their valuable feedback on this document. 858 Author's Address 860 Adam Barth 861 Google, Inc. 863 Email: ietf@adambarth.com 864 URI: http://www.adambarth.com/