1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
|
<pre>Internet Engineering Task Force (IETF) A. Barth
Request for Comments: 6454 Google, Inc.
Category: Standards Track December 2011
ISSN: 2070-1721
<span class="h1">The Web Origin Concept</span>
Abstract
This document defines the concept of an "origin", which is often used
as the scope of authority or privilege by user agents. Typically,
user agents isolate content retrieved from different origins to
prevent malicious web site operators from interfering with the
operation of benign web sites. In addition to outlining the
principles that underlie the concept of origin, this document details
how to determine the origin of a URI and how to serialize an origin
into a string. It also defines an HTTP header field, named "Origin",
that indicates which origins are associated with an HTTP request.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc6454">http://www.rfc-editor.org/info/rfc6454</a>.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
<span class="grey">Barth Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6454">RFC 6454</a> The Web Origin Concept December 2011</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2.1">2.1</a>. Conformance Criteria . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2.2">2.2</a>. Syntax Notation . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2.3">2.3</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3">3</a>. Principles of the Same-Origin Policy . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3.1">3.1</a>. Trust . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.1.1">3.1.1</a>. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.2">3.2</a>. Origin . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3.2.1">3.2.1</a>. Examples . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3.3">3.3</a>. Authority . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3.3.1">3.3.1</a>. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-3.4">3.4</a>. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-3.4.1">3.4.1</a>. Object Access . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-3.4.2">3.4.2</a>. Network Access . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-3.4.3">3.4.3</a>. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-3.5">3.5</a>. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-4">4</a>. Origin of a URI . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-5">5</a>. Comparing Origins . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-6">6</a>. Serializing Origins . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-6.1">6.1</a>. Unicode Serialization of an Origin . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-6.2">6.2</a>. ASCII Serialization of an Origin . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-7">7</a>. The HTTP Origin Header Field . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-7.1">7.1</a>. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-7.2">7.2</a>. Semantics . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-7.3">7.3</a>. User Agent Requirements . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-8">8</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-8.1">8.1</a>. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-8.2">8.2</a>. Divergent Units of Isolation . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-8.3">8.3</a>. Ambient Authority . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-8.4">8.4</a>. IDNA Dependency and Migration . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-9">9</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-10">10</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-10.1">10.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-10.2">10.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
<a href="#appendix-A">Appendix A</a>. Acknowledgements . . . . . . . . . . . . . . . . . . <a href="#page-20">20</a>
<span class="grey">Barth Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6454">RFC 6454</a> The Web Origin Concept December 2011</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
User agents interact with content created by a large number of
authors. Although many of those authors are well-meaning, some
authors might be malicious. To the extent that user agents undertake
actions based on content they process, user agent implementors might
wish to restrict the ability of malicious authors to disrupt the
confidentiality or integrity of other content or servers.
As an example, consider an HTTP user agent that renders HTML content
retrieved from various servers. If the user agent executes scripts
contained in those documents, the user agent implementor might wish
to prevent scripts retrieved from a malicious server from reading
documents stored on an honest server, which might, for example, be
behind a firewall.
Traditionally, user agents have divided content according to its
"origin". More specifically, user agents allow content retrieved
from one origin to interact freely with other content retrieved from
that origin, but user agents restrict how that content can interact
with content from another origin.
This document describes the principles behind the so-called same-
origin policy as well as the "nuts and bolts" of comparing and
serializing origins. This document does not describe all the facets
of the same-origin policy, the details of which are left to other
specifications, such as HTML [<a href="#ref-HTML" title=""HTML5"">HTML</a>] and WebSockets [<a href="./rfc6455" title=""The WebSocket Protocol"">RFC6455</a>], because
the details are often application-specific.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Conventions</span>
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Conformance Criteria</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
Requirements phrased in the imperative as part of algorithms (such as
"strip any leading space characters" or "return false and abort these
steps") are to be interpreted with the meaning of the key word
("MUST", "SHOULD", "MAY", etc.) used in introducing the algorithm.
Conformance requirements phrased as algorithms or specific steps can
be implemented in any manner, so long as the end result is
equivalent. In particular, the algorithms defined in this
specification are intended to be easy to understand and are not
intended to be performant.
<span class="grey">Barth Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6454">RFC 6454</a> The Web Origin Concept December 2011</span>
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Syntax Notation</span>
This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [<a href="./rfc5234" title=""Augmented BNF for Syntax Specifications: ABNF"">RFC5234</a>].
The following core rules are included by reference, as defined in
<a href="./rfc5234#appendix-B.1">[RFC5234], Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF
(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
sequence of data), SP (space), HTAB (horizontal tab), CHAR (any US-
ASCII character), VCHAR (any visible US-ASCII character), and WSP
(whitespace).
The OWS rule is used where zero or more linear whitespace octets
might appear. OWS SHOULD either not be produced or be produced as a
single SP. Multiple OWS octets that occur within field-content
SHOULD either be replaced with a single SP or transformed to all SP
octets (each octet other than SP replaced with SP) before
interpreting the field value or forwarding the message downstream.
OWS = *( SP / HTAB / obs-fold )
; "optional" whitespace
obs-fold = CRLF ( SP / HTAB )
; obsolete line folding
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Terminology</span>
The terms "user agent", "client", "server", "proxy", and "origin
server" have the same meaning as in the HTTP/1.1 specification
(<a href="./rfc2616#section-1.3">[RFC2616], Section 1.3</a>).
A globally unique identifier is a value that is different from all
other previously existing values. For example, a sufficiently long
random string is likely to be a globally unique identifier. If the
origin value never leaves the user agent, a monotonically increasing
counter local to the user agent can also serve as a globally unique
identifier.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Principles of the Same-Origin Policy</span>
Many user agents undertake actions on behalf of remote parties. For
example, HTTP user agents follow redirects, which are instructions
from remote servers, and HTML user agents expose rich Document Object
Model (DOM) interfaces to scripts retrieved from remote servers.
Without any security model, user agents might undertake actions
detrimental to the user or to other parties. Over time, many web-
related technologies have converged towards a common security model,
<span class="grey">Barth Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6454">RFC 6454</a> The Web Origin Concept December 2011</span>
known colloquially as the "same-origin policy". Although this
security model evolved largely organically, the same-origin policy
can be understood in terms of a handful of key concepts. This
section presents those concepts and provides advice about how to use
these concepts securely.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Trust</span>
The same-origin policy specifies trust by URI. For example, HTML
documents designate which script to run with a URI:
<script src="https://example.com/library.js"></script>
When a user agent processes this element, the user agent will fetch
the script at the designated URI and execute the script with the
privileges of the document. In this way, the document grants all the
privileges it has to the resource designated by the URI. In essence,
the document declares that it trusts the integrity of information
retrieved from that URI.
In addition to importing libraries from URIs, user agents also send
information to remote parties designated by URI. For example,
consider the HTML form element:
<form method="POST" action="https://example.com/login">
... <input type="password"> ...
</form>
When the user enters his or her password and submits the form, the
user agent sends the password to the network endpoint designated by
the URI. In this way, the document exports its secret data to that
URI, in essence declaring that it trusts the confidentiality of
information sent to that URI.
<span class="h4"><a class="selflink" id="section-3.1.1" href="#section-3.1.1">3.1.1</a>. Pitfalls</span>
When designing new protocols that use the same-origin policy, make
sure that important trust distinctions are visible in URIs. For
example, if both Transport Layer Security (TLS) and non-TLS protected
resources use the "http" URI scheme (as in [<a href="./rfc2817" title=""Upgrading to TLS Within HTTP/1.1"">RFC2817</a>]), a document
would be unable to specify that it wishes to retrieve a script only
over TLS. By using the "https" URI scheme, documents are able to
indicate that they wish to interact with resources that are protected
from active network attackers.
<span class="grey">Barth Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6454">RFC 6454</a> The Web Origin Concept December 2011</span>
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Origin</span>
In principle, user agents could treat every URI as a separate
protection domain and require explicit consent for content retrieved
from one URI to interact with another URI. Unfortunately, this
design is cumbersome for developers because web applications often
consist of a number of resources acting in concert.
Instead, user agents group URIs together into protection domains
called "origins". Roughly speaking, two URIs are part of the same
origin (i.e., represent the same principal) if they have the same
scheme, host, and port. (See <a href="#section-4">Section 4</a> for full details.)
Q: Why not just use the host?
A: Including the scheme in the origin tuple is essential for
security. If user agents did not include the scheme, there would be
no isolation between http://example.com and https://example.com
because the two have the same host. However, without this isolation,
an active network attacker could corrupt content retrieved from
http://example.com and have that content instruct the user agent to
compromise the confidentiality and integrity of content retrieved
from https://example.com, bypassing the protections afforded by TLS
[<a href="./rfc5246" title=""The Transport Layer Security (TLS) Protocol Version 1.2"">RFC5246</a>].
Q: Why use the fully qualified host name instead of just the "top-
level" domain?
A: Although the DNS has hierarchical delegation, the trust
relationships between host names vary by deployment. For example, at
many educational institutions, students can host content at
<a href="https://example.edu/~student/">https://example.edu/~student/</a>, but that does not mean a document
authored by a student should be part of the same origin (i.e.,
inhabit the same protection domain) as a web application for managing
grades hosted at <a href="https://grades.example.edu/">https://grades.example.edu/</a>.
The example.edu deployment illustrates that grouping resources by
origin does not always align perfectly with every deployment
scenario. In this deployment, every student's web site inhabits the
same origin, which might not be desirable. In some sense, the origin
granularity is a historical artifact of how the security model
evolved.
<span class="grey">Barth Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6454">RFC 6454</a> The Web Origin Concept December 2011</span>
<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a>. Examples</span>
All of the following resources have the same origin:
http://example.com/
<a href="http://example.com:80/">http://example.com:80/</a>
http://example.com/path/file
Each of the URIs has the same scheme, host, and port components.
Each of the following resources has a different origin from the
others.
http://example.com/
<a href="http://example.com:8080/">http://example.com:8080/</a>
http://www.example.com/
<a href="https://example.com:80/">https://example.com:80/</a>
https://example.com/
http://example.org/
<a href="http://ietf.org/">http://ietf.org/</a>
In each case, at least one of the scheme, host, and port component
will differ from the others in the list.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Authority</span>
Although user agents group URIs into origins, not every resource in
an origin carries the same authority (in the security sense of the
word "authority", not in the [<a href="./rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>] sense). For example, an image
is passive content and, therefore, carries no authority, meaning the
image has no access to the objects and resources available to its
origin. By contrast, an HTML document carries the full authority of
its origin, and scripts within (or imported into) the document can
access every resource in its origin.
User agents determine how much authority to grant a resource by
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 text/html are treated as HTML documents.
When hosting untrusted content (such as user-generated content), web
applications can limit that content's authority by restricting its
media type. For example, serving user-generated content as image/png
is less risky than serving user-generated content as text/html. Of
course, many web applications incorporate untrusted content in their
HTML documents. If not done carefully, these applications risk
leaking their origin's authority to the untrusted content, a
vulnerability commonly known as cross-site scripting.
<span class="grey">Barth Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6454">RFC 6454</a> The Web Origin Concept December 2011</span>
<span class="h4"><a class="selflink" id="section-3.3.1" href="#section-3.3.1">3.3.1</a>. Pitfalls</span>
When designing new pieces of the web platform, be careful not to
grant authority to resources irrespective of media type. Many web
applications serve untrusted content with restricted media types. A
new web platform feature that grants authority to these pieces of
content risks introducing vulnerabilities into existing applications.
Instead, prefer to grant authority to media types that already
possess the origin's full authority or to new media types designed
specifically to carry the new authority.
In order to remain compatible with servers that supply incorrect
media types, some user agents employ "content sniffing" and treat
content as if it had a different media type than the media type
supplied by the server. If not done carefully, content sniffing can
lead to security vulnerabilities because user agents might grant low-
authority media types, such as images, the privileges of high-
authority media types, such as HTML documents [<a href="#ref-SNIFF" title=""Media Type Sniffing"">SNIFF</a>].
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Policy</span>
Generally speaking, user agents isolate different origins and permit
controlled communication between origins. The details of how user
agents provide isolation and communication vary depending on several
factors.
<span class="h4"><a class="selflink" id="section-3.4.1" href="#section-3.4.1">3.4.1</a>. Object Access</span>
Most objects (also known as application programming interfaces or
APIs) exposed by the user agent are available only to the same
origin. Specifically, content retrieved from one URI can access
objects associated with content retrieved from another URI if, and
only if, the two URIs belong to the same origin, e.g., have the same
scheme, host, and port.
There are some exceptions to this general rule. For example, some
parts of HTML's Location interface are available across origins
(e.g., to allow for navigating other browsing contexts). As another
example, HTML's postMessage interface is visible across origins
explicitly to facilitate cross-origin communication. Exposing
objects to foreign origins is dangerous and should be done only with
great care because doing so exposes these objects to potential
attackers.
<span class="grey">Barth Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6454">RFC 6454</a> The Web Origin Concept December 2011</span>
<span class="h4"><a class="selflink" id="section-3.4.2" href="#section-3.4.2">3.4.2</a>. Network Access</span>
Access to network resources varies depending on whether the resources
are in the same origin as the content attempting to access them.
Generally, reading information from another origin is forbidden.
However, an origin is permitted to use some kinds of resources
retrieved from other origins. For example, an origin is permitted to
execute script, render images, and apply style sheets from any
origin. Likewise, an origin can display content from another origin,
such as an HTML document in an HTML frame. Network resources can
also opt into letting other origins read their information, for
example, using Cross-Origin Resource Sharing [<a href="#ref-CORS" title=""Cross-Origin Resource Sharing"">CORS</a>]. In these cases,
access is typically granted on a per-origin basis.
Sending information to another origin is permitted. However, sending
information over the network in arbitrary formats is dangerous. For
this reason, user agents restrict documents to sending information
using particular protocols, such as in an HTTP request without custom
headers. Expanding the set of allowed protocols, for example, by
adding support for WebSockets, must be done carefully to avoid
introducing vulnerabilities [<a href="./rfc6455" title=""The WebSocket Protocol"">RFC6455</a>].
<span class="h4"><a class="selflink" id="section-3.4.3" href="#section-3.4.3">3.4.3</a>. Pitfalls</span>
Whenever user agents allow one origin to interact with resources from
another origin, they invite security issues. For example, the
ability to display images from another origin leaks their height and
width. Similarly, the ability to send network requests to another
origin gives rise to cross-site request forgery vulnerabilities
[<a href="#ref-CSRF" title=""Robust Defenses for Cross-Site Request Forgery"">CSRF</a>]. However, user agent implementors often balance these risks
against the benefits of allowing the cross-origin interaction. For
example, an HTML user agent that blocked cross-origin network
requests would prevent its users from following hyperlinks, a core
feature of the web.
When adding new functionality to the web platform, it can be tempting
to grant a privilege to one resource but to withhold that privilege
from another resource in the same origin. However, withholding
privileges in this way is ineffective because the resource without
the privilege can usually obtain the privilege anyway because user
agents do not isolate resources within an origin. Instead,
privileges should be granted or withheld from origins as a whole
(rather than discriminating between individual resources within an
origin) [<a href="#ref-BOFGO" title=""Beware of Finer-Grained Origins"">BOFGO</a>].
<span class="grey">Barth Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6454">RFC 6454</a> The Web Origin Concept December 2011</span>
<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>. Conclusion</span>
The same-origin policy uses URIs to designate trust relationships.
URIs are grouped together into origins, which represent protection
domains. Some resources in an origin (e.g., active content) are
granted the origin's full authority, whereas other resources in the
origin (e.g., passive content) are not granted the origin's
authority. Content that carries its origin's authority is granted
access to objects and network resources within its own origin. This
content is also granted limited access to objects and network
resources of other origins, but these cross-origin privileges must be
designed carefully to avoid security vulnerabilities.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Origin of a URI</span>
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
authority (see <a href="./rfc3986#section-3.2">[RFC3986], Section 3.2</a>) or if the URI is not an
absolute URI, then generate a fresh globally unique identifier
and return that value.
NOTE: Running this algorithm multiple times for the same URI
can produce different values each time. Typically, user
agents compute the origin of, for example, an HTML document
once and use that origin for subsequent security checks rather
than recomputing the origin for each security check.
2. Let uri-scheme be the scheme component of the URI, converted to
lowercase.
3. If the implementation doesn't support the protocol given by uri-
scheme, then generate a fresh globally unique identifier and
return that value.
4. If uri-scheme is "file", the implementation MAY return an
implementation-defined value.
NOTE: Historically, user agents have granted content from the
file scheme a tremendous amount of privilege. However,
granting all local files such wide privileges can lead to
privilege escalation attacks. Some user agents have had
success granting local files directory-based privileges, but
this approach has not been widely adopted. Other user agents
use globally unique identifiers for each file URI, which is
the most secure option.
<span class="grey">Barth Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6454">RFC 6454</a> The Web Origin Concept December 2011</span>
5. Let uri-host be the host component of the URI, converted to lower
case (using the i;ascii-casemap collation defined in [<a href="./rfc4790" title=""Internet Application Protocol Collation Registry"">RFC4790</a>]).
NOTE: This document assumes that the user agent performs
Internationalizing Domain Names in Applications (IDNA)
processing and validation when constructing the URI. In
particular, this document assumes the uri-host will contain
only LDH labels because the user agent will have already
converted any non-ASCII labels to their corresponding A-labels
(see [<a href="./rfc5890" title=""Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework"">RFC5890</a>]). For this reason, origin-based security
policies are sensitive to the IDNA algorithm employed by the
user agent. See <a href="#section-8.4">Section 8.4</a> for further discussion.
6. If there is no port component of the URI:
1. Let uri-port be the default port for the protocol given by
uri-scheme.
Otherwise:
2. Let uri-port be the port component of the URI.
7. Return the triple (uri-scheme, uri-host, uri-port).
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Comparing Origins</span>
Two origins are "the same" if, and only if, they are identical. In
particular:
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,
and ports.
o An origin that is a globally unique identifier cannot be the same
as an origin that is a scheme/host/port triple.
Two URIs are same-origin if their origins are the same.
NOTE: A URI is not necessarily same-origin with itself. For
example, a data URI [<a href="./rfc2397" title=""The "">RFC2397</a>] is not same-origin with itself
because data URIs do not use a server-based naming authority and
therefore have globally unique identifiers as origins.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Serializing Origins</span>
This section defines how to serialize an origin to a unicode
[<a href="#ref-Unicode6" title=""The Unicode Standard, Version 6.0.0"">Unicode6</a>] string and to an ASCII [<a href="./rfc20" title=""ASCII format for network interchange"">RFC20</a>] string.
<span class="grey">Barth Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6454">RFC 6454</a> The Web Origin Concept December 2011</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Unicode Serialization of an Origin</span>
The unicode-serialization of an origin is the value returned by the
following algorithm:
1. If the origin is not a scheme/host/port triple, then return the
string
null
(i.e., the code point sequence U+006E, U+0075, U+006C, U+006C)
and abort these steps.
2. Otherwise, let result be the scheme part of the origin triple.
3. Append the string "://" to result.
4. Append each component of the host part of the origin triple
(converted as follows) to the result, separated by U+002E FULL
STOP code points ("."):
1. If the component is an A-label, use the corresponding U-label
instead (see [<a href="./rfc5890" title=""Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework"">RFC5890</a>] and [<a href="./rfc5891" title=""Internationalized Domain Names in Applications (IDNA): Protocol"">RFC5891</a>]).
2. Otherwise, use the component verbatim.
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
origin triple:
1. Append a U+003A COLON code point (":") and the given port, in
base ten, to result.
6. Return result.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. ASCII Serialization of an Origin</span>
The ascii-serialization of an origin is the value returned by the
following algorithm:
1. If the origin is not a scheme/host/port triple, then return the
string
null
(i.e., the code point sequence U+006E, U+0075, U+006C, U+006C)
and abort these steps.
<span class="grey">Barth Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6454">RFC 6454</a> The Web Origin Concept December 2011</span>
2. Otherwise, let result be the scheme part of the origin triple.
3. Append the string "://" to result.
4. Append the host part of the origin triple to result.
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
origin triple:
1. Append a U+003A COLON code point (":") and the given port, in
base ten, to result.
6. Return result.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. The HTTP Origin Header Field</span>
This section defines the HTTP Origin header field.
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Syntax</span>
The Origin header field has the following syntax:
origin = "Origin:" OWS origin-list-or-null OWS
origin-list-or-null = %x6E %x75 %x6C %x6C / origin-list
origin-list = serialized-origin *( SP serialized-origin )
serialized-origin = scheme "://" host [ ":" port ]
; <scheme>, <host>, <port> from <a href="./rfc3986">RFC 3986</a>
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Semantics</span>
When included in an HTTP request, the Origin header field indicates
the origin(s) that "caused" the user agent to issue the request, as
defined by the API that triggered the user agent to issue the
request.
For example, consider a user agent that executes scripts on behalf of
origins. If one of those scripts causes the user agent to issue an
HTTP request, the user agent MAY use the Origin header field to
inform the server of the security context in which the script was
executing when it caused the user agent to issue the request.
In some cases, a number of origins contribute to causing the user
agents to issue an HTTP request. In those cases, the user agent MAY
list all the origins in the Origin header field. For example, if the
HTTP request was initially issued by one origin but then later
<span class="grey">Barth Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc6454">RFC 6454</a> The Web Origin Concept December 2011</span>
redirected by another origin, the user agent MAY inform the server
that two origins were involved in causing the user agent to issue the
request.
<span class="h3"><a class="selflink" id="section-7.3" href="#section-7.3">7.3</a>. User Agent Requirements</span>
The user agent MAY include an Origin header field in any HTTP
request.
The user agent MUST NOT include more than one Origin header field in
any HTTP request.
Whenever a user agent issues an HTTP request from a "privacy-
sensitive" context, the user agent MUST send the value "null" in the
Origin header field.
NOTE: This document does not define the notion of a privacy-
sensitive context. Applications that generate HTTP requests can
designate contexts as privacy-sensitive to impose restrictions on
how user agents generate Origin header fields.
When generating an Origin header field, the user agent MUST meet the
following requirements:
o Each of the serialized-origin productions in the grammar MUST be
the ascii-serialization of an origin.
o No two consecutive serialized-origin productions in the grammar
can be identical. In particular, if the user agent would generate
two consecutive serialized-origins, the user agent MUST NOT
generate the second one.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Security Considerations</span>
The same-origin policy is one of the cornerstones of security for
many user agents, including web browsers. Historically, some user
agents tried other security models, including taint tracking and
exfiltration prevention, but those models proved difficult to
implement at the time (although there has been recent interest in
reviving some of these ideas).
Evaluating the security of the same-origin policy is difficult
because the origin concept itself plays such a central role in the
security landscape. The notional origin itself is just a unit of
isolation, imperfect as are most one-size-fits-all notions. That
said, there are some systemic weaknesses, discussed below.
<span class="grey">Barth Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc6454">RFC 6454</a> The Web Origin Concept December 2011</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Reliance on DNS</span>
In practice, the same-origin policy relies upon the Domain Name
System (DNS) for security because many commonly used URI schemes,
such as http, use DNS-based naming authorities. If the DNS is
partially or fully compromised, the same-origin policy might fail to
provide the security properties required by applications.
Some URI schemes, such as https, are more resistant to DNS compromise
because user agents employ other mechanisms, such as certificates, to
verify the source of content retrieved from these URIs. Other URI
schemes, such as the chrome-extension URI scheme (see Section 4.3 of
[<a href="#ref-CRX" title=""Protecting Browsers from Extension Vulnerabilities"">CRX</a>]), use a public-key-based naming authority and are fully secure
against DNS compromise.
The web origin concept isolates content retrieved from different URI
schemes; this is essential to containing the effects of DNS
compromise.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Divergent Units of Isolation</span>
Over time, a number of technologies have converged on the web origin
concept as a convenient unit of isolation. However, many
technologies in use today, such as cookies [<a href="./rfc6265" title=""HTTP State Management Mechanism"">RFC6265</a>], pre-date the
modern web origin concept. These technologies often have different
isolation units, leading to vulnerabilities.
One alternative is to use only the "registry-controlled" domain
rather than the fully qualified domain name as the unit of isolation
(e.g., "example.com" instead of "www.example.com"). This practice is
problematic for a number of reasons and is NOT RECOMMENDED:
1. The notion of a "registry-controlled" domain is a function of
human practice surrounding the DNS rather than a property of the
DNS itself. For example, many municipalities in Japan run public
registries quite deep in the DNS hierarchy. There are widely
used "public suffix lists", but these lists are difficult to keep
up to date and vary between implementations.
2. This practice is incompatible with URI schemes that do not use a
DNS-based naming authority. For example, if a given URI scheme
uses public keys as naming authorities, the notion of a
"registry-controlled" public key is somewhat incoherent. Worse,
some URI schemes, such as nntp, use dotted delegation in the
opposite direction from DNS (e.g., alt.usenet.kooks), and others
use the DNS but present the labels in the reverse of the usual
order (e.g., com.example.www).
<span class="grey">Barth Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc6454">RFC 6454</a> The Web Origin Concept December 2011</span>
At best, using "registry-controlled" domains is URI-scheme- and
implementation-specific. At worst, differences between URI schemes
and implementations can lead to vulnerabilities.
<span class="h3"><a class="selflink" id="section-8.3" href="#section-8.3">8.3</a>. Ambient Authority</span>
When using the same-origin policy, user agents grant authority to
content based on its URI rather than based on which objects the
content can designate. This disentangling of designation from
authority is an example of ambient authority and can lead to
vulnerabilities.
Consider, for example, cross-site scripting in HTML documents. If an
attacker can inject script content into an HTML document, those
scripts will run with the authority of the document's origin, perhaps
allowing the script access to sensitive information, such as the
user's medical records. If, however, the script's authority were
limited to those objects that the script could designate, the
attacker would not gain any advantage by injecting the script into an
HTML document hosted by a third party.
<span class="h3"><a class="selflink" id="section-8.4" href="#section-8.4">8.4</a>. IDNA Dependency and Migration</span>
The security properties of the same-origin policy can depend
crucially on details of the IDNA algorithm employed by the user
agent. In particular, a user agent might map some international
domain names (for example, those involving the U+00DF character) to
different ASCII representations depending on whether the user agent
uses IDNA2003 [<a href="./rfc3490" title=""Internationalizing Domain Names in Applications (IDNA)"">RFC3490</a>] or IDNA2008 [<a href="./rfc5890" title=""Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework"">RFC5890</a>].
Migrating from one IDNA algorithm to another might redraw a number of
security boundaries, potentially erecting new security boundaries or,
worse, tearing down security boundaries between two mutually
distrusting entities. Changing security boundaries is risky because
combining two mutually distrusting entities into the same origin
might allow one to attack the other.
<span class="grey">Barth Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc6454">RFC 6454</a> The Web Origin Concept December 2011</span>
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. IANA Considerations</span>
The permanent message header field registry (see [<a href="./rfc3864" title=""Registration Procedures for Message Header Fields"">RFC3864</a>]) has been
updated with the following registration:
Header field name: Origin
Applicable protocol: http
Status: standard
Author/Change controller: IETF
Specification document: this specification (<a href="#section-7">Section 7</a>)
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. References</span>
<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>. Normative References</span>
[<a id="ref-RFC20">RFC20</a>] Cerf, V., "ASCII format for network interchange", <a href="./rfc20">RFC 20</a>,
October 1969.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC2616">RFC2616</a>] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", <a href="./rfc2616">RFC 2616</a>, June 1999.
[<a id="ref-RFC3864">RFC3864</a>] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", <a href="https://www.rfc-editor.org/bcp/bcp90">BCP 90</a>, <a href="./rfc3864">RFC 3864</a>,
September 2004.
[<a id="ref-RFC3986">RFC3986</a>] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
<a href="./rfc3986">RFC 3986</a>, January 2005.
[<a id="ref-RFC4790">RFC4790</a>] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet
Application Protocol Collation Registry", <a href="./rfc4790">RFC 4790</a>,
March 2007.
[<a id="ref-RFC5234">RFC5234</a>] Crocker, D., Ed. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, <a href="./rfc5234">RFC 5234</a>,
January 2008.
[<a id="ref-RFC5890">RFC5890</a>] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
<a href="./rfc5890">RFC 5890</a>, August 2010.
<span class="grey">Barth Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc6454">RFC 6454</a> The Web Origin Concept December 2011</span>
[<a id="ref-RFC5891">RFC5891</a>] Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", <a href="./rfc5891">RFC 5891</a>, August 2010.
[<a id="ref-Unicode6">Unicode6</a>] The Unicode Consortium, "The Unicode Standard, Version
6.0.0", 2011,
<<a href="http://www.unicode.org/versions/Unicode6.0.0/">http://www.unicode.org/versions/Unicode6.0.0/</a>>.
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Informative References</span>
[<a id="ref-BOFGO">BOFGO</a>] Jackson, C. and A. Barth, "Beware of Finer-Grained
Origins", 2008,
<<a href="http://w2spconf.com/2008/papers/s2p1.pdf">http://w2spconf.com/2008/papers/s2p1.pdf</a>>.
[<a id="ref-CORS">CORS</a>] van Kesteren, A., "Cross-Origin Resource Sharing", W3C
Working Draft WD-cors-20100727, July 2010,
<<a href="http://www.w3.org/TR/2010/WD-cors-20100727/">http://www.w3.org/TR/2010/WD-cors-20100727/</a>>.
Latest version available at <<a href="http://www.w3.org/TR/cors/">http://www.w3.org/TR/cors/</a>>.
[<a id="ref-CRX">CRX</a>] Barth, A., Felt, A., Saxena, P., and A. Boodman,
"Protecting Browsers from Extension Vulnerabilities",
2010, <<a href="http://www.isoc.org/isoc/conferences/ndss/10/pdf/04.pdf">http://www.isoc.org/isoc/conferences/ndss/10/pdf/</a>
<a href="http://www.isoc.org/isoc/conferences/ndss/10/pdf/04.pdf">04.pdf</a>>.
[<a id="ref-CSRF">CSRF</a>] Barth, A., Jackson, C., and J. Mitchell, "Robust Defenses
for Cross-Site Request Forgery", 2008,
<<a href="http://portal.acm.org/citation.cfm?id=1455770.1455782">http://portal.acm.org/citation.cfm?id=1455770.1455782</a>>.
[<a id="ref-HTML">HTML</a>] Hickson, I., "HTML5", W3C Working Draft WD-html5-
20110525, May 2011,
<<a href="http://www.w3.org/TR/2011/WD-html5-20110525/">http://www.w3.org/TR/2011/WD-html5-20110525/</a>>.
Latest version available at
<<a href="http://www.w3.org/TR/html5/">http://www.w3.org/TR/html5/</a>>.
[<a id="ref-RFC2397">RFC2397</a>] Masinter, L., "The "data" URL scheme", <a href="./rfc2397">RFC 2397</a>,
August 1998.
[<a id="ref-RFC2817">RFC2817</a>] Khare, R. and S. Lawrence, "Upgrading to TLS Within
HTTP/1.1", <a href="./rfc2817">RFC 2817</a>, May 2000.
[<a id="ref-RFC3490">RFC3490</a>] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
<a href="./rfc3490">RFC 3490</a>, March 2003.
[<a id="ref-RFC5246">RFC5246</a>] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", <a href="./rfc5246">RFC 5246</a>, August 2008.
<span class="grey">Barth Standards Track [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc6454">RFC 6454</a> The Web Origin Concept December 2011</span>
[<a id="ref-RFC6265">RFC6265</a>] Barth, A., "HTTP State Management Mechanism", <a href="./rfc6265">RFC 6265</a>,
April 2011.
[<a id="ref-RFC6455">RFC6455</a>] Fette, I. and A. Melnikov, "The WebSocket Protocol",
<a href="./rfc6455">RFC 6455</a>, December 2011.
[<a id="ref-SNIFF">SNIFF</a>] Barth, A. and I. Hickson, <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&q=inurl:draft-+%22Media+Type+Sniffing%22'>"Media Type Sniffing"</a>, Work
in Progress, May 2011.
<span class="grey">Barth Standards Track [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc6454">RFC 6454</a> The Web Origin Concept December 2011</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Acknowledgements</span>
We would like to thank Lucas Adamski, Stephen Farrell, Miguel A.
Garcia, Tobias Gondrom, Ian Hickson, Anne van Kesteren, Jeff Hodges,
Collin Jackson, Larry Masinter, Alexey Melnikov, Mark Nottingham,
Julian Reschke, Peter Saint-Andre, Jonas Sicking, Sid Stamm, Daniel
Veditz, and Chris Weber for their valuable feedback on this document.
Author's Address
Adam Barth
Google, Inc.
EMail: ietf@adambarth.com
URI: <a href="http://www.adambarth.com/">http://www.adambarth.com/</a>
Barth Standards Track [Page 20]
</pre>
|
