├── .gitignore ├── .pr-preview.json ├── LICENSE.md ├── w3c.json ├── README.md ├── CODE_OF_CONDUCT.md ├── .github └── workflows │ └── build.yml ├── Makefile ├── CONTRIBUTING.md ├── published ├── default.css ├── 2014-08-07-REFERRER-FPWD.html └── 2016-06-01-REFERRER-WD.html └── index.src.html /.gitignore: -------------------------------------------------------------------------------- 1 | index.html 2 | -------------------------------------------------------------------------------- /.pr-preview.json: -------------------------------------------------------------------------------- 1 | { 2 | "src_file": "index.src.html", 3 | "type": "bikeshed", 4 | "params": { 5 | "force": 1 6 | } 7 | } 8 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | All documents in this Repository are licensed by contributors under the [W3C Document 2 | License](http://www.w3.org/Consortium/Legal/copyright-documents). 3 | -------------------------------------------------------------------------------- /w3c.json: -------------------------------------------------------------------------------- 1 | { 2 | "group": [ 3 | "49309" 4 | ], 5 | "contacts": [ 6 | "wseltzer" 7 | ], 8 | "shortName": "referrer-policy", 9 | "repo-type": "rec-track" 10 | } -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | 2 | # Specification 'webappsec-referrer-policy' 3 | 4 | This is the repository for webappsec-referrer-policy. You're welcome to contribute! Let's make the Web rock our socks 5 | off! 6 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Code of Conduct 2 | 3 | All documentation, code and communication under this repository are covered by the [W3C Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/). 4 | -------------------------------------------------------------------------------- /.github/workflows/build.yml: -------------------------------------------------------------------------------- 1 | name: Build 2 | on: 3 | pull_request: 4 | branches: 5 | - main 6 | push: 7 | branches: 8 | - main 9 | jobs: 10 | build: 11 | name: Build 12 | runs-on: ubuntu-latest 13 | steps: 14 | - uses: actions/checkout@v2 15 | - name: Build 16 | run: make ci 17 | - name: Deploy 18 | if: ${{ github.event_name == 'push' && github.ref == 'refs/heads/main' }} 19 | uses: peaceiris/actions-gh-pages@v3 20 | with: 21 | github_token: ${{ secrets.GITHUB_TOKEN }} 22 | publish_dir: ./out 23 | -------------------------------------------------------------------------------- /Makefile: -------------------------------------------------------------------------------- 1 | SHELL=/bin/bash 2 | 3 | .PHONY: ci clean local remote 4 | 5 | local: index.src.html 6 | bikeshed --die-on=warning spec index.src.html index.html 7 | 8 | remote: index.html 9 | 10 | ci: index.src.html index.html 11 | mkdir -p out 12 | cp index.html out/ 13 | 14 | clean: 15 | rm index.html 16 | 17 | index.html: index.src.html 18 | @ (HTTP_STATUS=$$(curl https://api.csswg.org/bikeshed/ \ 19 | --output index.html \ 20 | --write-out "%{http_code}" \ 21 | --header "Accept: text/plain, text/html" \ 22 | -F die-on=warning \ 23 | -F file=@index.src.html) && \ 24 | [[ "$$HTTP_STATUS" -eq "200" ]]) || ( \ 25 | echo ""; cat index.html; echo ""; \ 26 | rm -f index.html; \ 27 | exit 22 \ 28 | ); 29 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Web Application Security Working Group 2 | 3 | Contributions to this repository are intended to become part of Recommendation-track documents 4 | governed by the [W3C Patent Policy](https://www.w3.org/Consortium/Patent-Policy/) and 5 | [Document License](https://www.w3.org/Consortium/Legal/copyright-documents). To contribute, you must 6 | either participate in the relevant W3C Working Group or make a non-member patent licensing 7 | commitment. 8 | 9 | If you are not the sole contributor to a contribution (pull request), please identify all 10 | contributors in the pull request's body or in subsequent comments. 11 | 12 | To add a contributor (other than yourself, that's automatic), mark them one per line as follows: 13 | 14 | ``` 15 | +@github_username 16 | ``` 17 | 18 | If you added a contributor by mistake, you can remove them in a comment with: 19 | 20 | ``` 21 | -@github_username 22 | ``` 23 | 24 | If you are making a pull request on behalf of someone else but you had no part in designing the 25 | feature, you can remove yourself with the above syntax. 26 | 27 | # Tests 28 | 29 | See [CONTRIBUTING.md](https://github.com/w3c/webappsec/blob/master/CONTRIBUTING.md). 30 | -------------------------------------------------------------------------------- /published/default.css: -------------------------------------------------------------------------------- 1 | /* 2 | * Style sheet for WebAppSec specifications (stolen wholesale from the CSSWG), 3 | * to be used in addition to http://www.w3.org/StyleSheets/TR/W3C-{WD,PR,REC} 4 | */ 5 | 6 | @media print { 7 | html { margin: 0 !important } 8 | body { font-family: serif } 9 | th, td { font-family: inherit } 10 | a { color: inherit !important } 11 | .example:before { font-family: serif !important } 12 | a:link, a:visited { text-decoration: none !important } 13 | a:link:after, a:visited:after { /* create a cross-ref "see..." */ } 14 | } 15 | @page { 16 | margin: 1.5cm 1.1cm; 17 | } 18 | 19 | body { 20 | counter-reset: exampleno figure issue; 21 | max-width: 50em; 22 | margin: 0 auto !important; 23 | } 24 | 25 | /* Pagination */ 26 | h1, h2, h3, h4, h5, h6 { page-break-after: avoid } 27 | figure, div.figure, div.sidefigure, pre, table.propdef, table.propdef-extra, 28 | .example { page-break-inside: avoid } 29 | dt { page-break-after: avoid } 30 | 31 | span.id {float: right; font-weight: bold} 32 | 33 | /* General Structural Markup */ 34 | h2, h3, h5, h6 { margin-top: 3em; } 35 | 36 | /* #subtitle is a subtitle in an H2 under the H1 */ 37 | h1 + h2, #subtitle + h2 { margin-top: 0; } 38 | 39 | h4 { margin-top: 4em; } 40 | 41 | h2 + h3, h3 + h4, h4 + h5, h5 + h6 { margin-top: 1.2em } 42 | 43 | hr:not([title]) { 44 | font-size: 1.5em; 45 | text-align: center; 46 | margin: 1em auto; 47 | border: transparent solid; 48 | background: transparent; 49 | } 50 | hr:not([title])::before { 51 | content: "\1F411\2003\2003\1F411\2003\2003\1F411"; 52 | } 53 | 54 | p, div.note, div.issue, details.why { 55 | margin-top: 1em; 56 | margin-bottom: 1em; 57 | } 58 | 59 | dd > p:first-child, li > p:first-child, .note > p:first-child, .issue > p:first-child { 60 | margin-top: 0 61 | } 62 | 63 | pre { 64 | margin-top: 1em; 65 | margin-bottom: 1em; 66 | } 67 | 68 | pre, code { 69 | font-family: Menlo, Consolas, "DejaVu Sans Mono", monospace; 70 | font-size: .9em; 71 | } 72 | 73 | img { 74 | border-style: none; 75 | color: white; 76 | } 77 | .toc { 78 | } 79 | 80 | body { 81 | line-height: 1.5; 82 | } 83 | 84 | a:link, a:visited { 85 | border-bottom: 1px solid silver; 86 | color: inherit; 87 | text-decoration: none; 88 | } 89 | 90 | a.logo:link, a.logo:visited { 91 | padding: 0; 92 | border-style: none; 93 | } 94 | 95 | dl dd { margin: 0 0 1em 2em } 96 | .head dd { margin-bottom: 0; } 97 | ul, ol { margin-left: 0; padding-left: 2em; } 98 | li { margin: 0.25em 2em 0.5em 0; padding-left: 0 } 99 | 100 | ul.indexlist { margin-left: 0; columns: 13em; } 101 | ul.indexlist li { margin-left: 0; list-style: none } 102 | ul.indexlist li li { margin-left: 1em } 103 | ul.indexlist a { font-weight: bold; } 104 | ul.indexlist ul, ul.indexlist dl { font-size: smaller; } 105 | ul.indexlist dl { margin-top: 0; } 106 | ul.indexlist dt { margin: .2em 0 .2em 20px;} 107 | ul.indexlist dd { margin: .2em 0 .2em 40px;} 108 | 109 | /* .self-link is a link to the element */ 110 | .heading, .issue, .note, .example, li, dt { position: relative; } 111 | a.self-link { 112 | position: absolute; 113 | top: 0; 114 | left: -2.5em; 115 | width: 2em; 116 | height: 2em; 117 | text-align: center; 118 | border: none; 119 | transition: opacity .2s; 120 | opacity: .5; 121 | } 122 | a.self-link:hover { 123 | opacity: 1; 124 | } 125 | .heading > a.self-link { 126 | font-size: 83%; 127 | } 128 | li > a.self-link { 129 | left: -3.5em; 130 | } 131 | dfn > a.self-link { 132 | top: auto; 133 | left: auto; 134 | opacity: 0; 135 | width: 1.5em; 136 | height: 1.5em; 137 | background: gray; 138 | color: white; 139 | font-style: normal; 140 | transition: opacity .2s, background-color .2s, color .2s; 141 | } 142 | dfn:hover > a.self-link { 143 | opacity: 1; 144 | } 145 | dfn > a.self-link:hover { 146 | color: black; 147 | } 148 | 149 | a.self-link::before { content: "¶"; } 150 | .heading > a.self-link::before { content: "§"; } 151 | dfn > a.self-link::before { content: "#"; } 152 | 153 | /* Examples */ 154 | 155 | .example { 156 | counter-increment: exampleno; 157 | } 158 | .example:before { 159 | content: "Example"; 160 | content: "Example " counter(exampleno); 161 | min-width: 7.5em; 162 | text-transform: uppercase; 163 | display: block; 164 | } 165 | div.illegal-example:before, pre.illegal-example:before { 166 | content: "Invalid Example"; 167 | content: "Invalid Example" counter(exampleno); 168 | } 169 | .example, .illegal-example, div.html, div.illegal-html, div.xml, 170 | div.illegal-xml, pre.html, 171 | pre.illegal-html, pre.xml, pre.illegal-xml { 172 | padding: 0.5em; 173 | margin: 1em 0; 174 | position: relative; 175 | clear: both; 176 | } 177 | pre.example, pre.illegal-example, pre.html, 178 | pre.illegal-html, pre.xml, pre.illegal-xml { 179 | padding-top: 1.5em; 180 | } 181 | pre.illegal-example { color: red } 182 | div.illegal-example { color: red } 183 | div.illegal-example p { color: black } 184 | 185 | div.html { color: #600 } 186 | pre.html { color: #600 } 187 | pre.illegal-html { color: red } 188 | div.illegal-html { color: red } 189 | div.illegal-html p { color: black } 190 | pre.deprecated-html { color: red } 191 | div.deprecated-html { color: red } 192 | div.deprecated-html p { color: black } 193 | 194 | div.xml { color: #600 } 195 | pre.xml { color: #600 } 196 | pre.illegal-xml { color: red } 197 | div.illegal-xml { color: red } 198 | div.illegal-xml p { color: black } 199 | 200 | .css, .property { color: #005a9c } /* inline CSS code (SPAN/CODE) */ 201 | code.css { font-family: inherit; font-size: 100% } 202 | code.html { color: #600 } /* inline HTML */ 203 | code.xml { color: #600 } /* inline XML */ 204 | .property { font: inherit; white-space: nowrap; } /* name of a CSS property (SPAN) */ 205 | .descriptor { } /* name of a CSS descriptor (SPAN) */ 206 | .type { font-style: italic } /* A value for a property */ 207 | 208 | /* Autolinks produced using Bikeshed. */ 209 | [data-link-type="property"]::before, 210 | [data-link-type="propdesc"]::before, 211 | [data-link-type="descriptor"]::before, 212 | [data-link-type="value"]::before, 213 | [data-link-type="function"]::before, 214 | [data-link-type="at-rule"]::before, 215 | [data-link-type="selector"]::before, 216 | [data-link-type="maybe"]::before {content: "\2018";} 217 | [data-link-type="property"]::after, 218 | [data-link-type="propdesc"]::after, 219 | [data-link-type="descriptor"]::after, 220 | [data-link-type="value"]::after, 221 | [data-link-type="function"]::after, 222 | [data-link-type="at-rule"]::after, 223 | [data-link-type="selector"]::after, 224 | [data-link-type="maybe"]::after {content: "\2019";} 225 | [data-link-type].production::before, 226 | [data-link-type].production::after, 227 | .prod [data-link-type]::before, 228 | .prod [data-link-type]::after { content: ""; } 229 | 230 | 231 | /* Element-type link styling */ 232 | [data-link-type=element] { font-family: monospace; } 233 | [data-link-type=element]::before { content: "<" } 234 | [data-link-type=element]::after { content: ">" } 235 | 236 | dfn { font-weight: bolder; } 237 | a > i { font-style: normal; } /* Instance of term */ 238 | 239 | .issue, .note, .example, .why { 240 | padding: .5em; 241 | /* padding: .5rem; /* proposed unit in css3-values */ 242 | border-left-width: .5em; 243 | /* border-left-width: .5rem; /* proposed unit in css3-values */ 244 | border-left-style: solid; 245 | } 246 | span.note, span.issue { 247 | padding: .1em .5em .15em; 248 | border-right-width: .5em; 249 | border-right-style: solid; 250 | } 251 | 252 | /* Open issue / editorial remark; not intended for a final publication */ 253 | .issue { 254 | border-color: #E05252; 255 | background: #FBE9E9; 256 | counter-increment: issue; 257 | overflow: auto; 258 | } 259 | 260 | .issue:before { 261 | content: "Issue " counter(issue); 262 | padding-right: 1em; 263 | text-transform: uppercase; 264 | color: #E05252; 265 | } 266 | 267 | /* Class note is a non-normative note. May be inline or a P or DIV */ 268 | .note, .why { 269 | border-color: #52E052; 270 | background: #E9FBE9; 271 | overflow: auto; 272 | } 273 | 274 | .normref { color: red } 275 | .informref { color: green } 276 | 277 | /* Example box */ 278 | .example { 279 | border-color: #E0CB52; 280 | background: #FCFAEE; 281 | overflow: auto; 282 | } 283 | 284 | .example:before { 285 | color: #B9AB2D; 286 | font-family: sans-serif; 287 | } 288 | 289 | details.why { 290 | border-color: #52E052; 291 | background: #E9FBE9; 292 | display: block; 293 | } 294 | 295 | details.why > summary { 296 | font-style: italic; 297 | display: block; 298 | } 299 | 300 | details.why[open] > summary { 301 | border-bottom: 1px silver solid; 302 | } 303 | 304 | /* ToC not indented, but font style shows hierarchy */ 305 | ul.toc {margin: 1em 0; padding: 0; line-height: 1.3; font-weight: bold; /*text-transform: uppercase;*/ } 306 | ul.toc ul {margin: 0; padding: 0; font-weight: normal; text-transform: none; } 307 | ul.toc ul ul {margin: 0 0 0 2em; font-style: italic; } 308 | ul.toc ul ul ul {margin: 0} 309 | ul.toc > li {margin: 1.5em 0; padding: 0; } 310 | ul.toc ul.toc li { margin: 0.3em 0 0 0; } 311 | ul.toc a { text-decoration: none; border-bottom-style: none; } 312 | ul.toc a:hover, ul.toc a:focus { border-bottom-style: solid; } 313 | /* 314 | ul.toc li li li, ul.toc li li li ul {margin-left: 0; display: inline} 315 | ul.toc li li li ul, ul.toc li li li ul li {margin-left: 0; display: inline} 316 | */ 317 | 318 | /* Section numbers in a column of their own */ 319 | ul.toc span.secno {float: left; width: 4em; margin-left: -5em} 320 | ul.toc ul ul span.secno { margin-left: -7em; } 321 | /*ul.toc span.secno {text-align: right}*/ 322 | ul.toc li {clear: both} 323 | ul.toc {margin-left: 5em} 324 | /* If we had 'tab', floats would not be needed here: 325 | ul.toc span.secno {tab: 5em right; margin-right: 1em} 326 | ul.toc li {text-indent: 5em hanging} 327 | The second line in case items wrap 328 | */ 329 | 330 | ul.index { 331 | list-style: none; 332 | } 333 | 334 | s, del {text-decoration: line-through; color: red} 335 | u, ins {text-decoration: underline; color: #080} 336 | 337 | div.figure, p.figure, div.sidefigure, figure { 338 | text-align: center; 339 | margin: 2.5em 0; 340 | } 341 | div.figure pre, div.sidefigure pre, figure pre { 342 | text-align: left; 343 | display: table; 344 | margin: 1em auto; 345 | } 346 | .figure table, figure table { 347 | margin: auto; 348 | } 349 | div.sidefigure, figure.sidefigure { 350 | float: right; 351 | width: 50%; 352 | margin: 0 0 0.5em 0.5em 353 | } 354 | div.figure img, div.sidefigure img, figure img, 355 | div.figure object, div.sidefigure object, figure object { 356 | display: block; 357 | margin: auto; 358 | max-width: 100% 359 | } 360 | p.caption, figcaption, caption { 361 | text-align: center; 362 | font-style: italic; 363 | font-size: 90%; 364 | } 365 | p.caption:before, figcaption:before { 366 | content: "Figure " counter(figure) ". "; 367 | font-weight: bold; 368 | } 369 | p.caption, figcaption { 370 | counter-increment: figure; 371 | } 372 | 373 | /* DL list is indented, but figure inside it is not */ 374 | dd { margin-left: 2em } 375 | dd div.figure, dd figure { margin-left: -2em } 376 | 377 | sup { 378 | vertical-align: super; 379 | font-size: 80% 380 | } 381 | 382 | /* "Equations" (not real MathML, but simple HTML) are put in a 383 | blockquote and may have an equation number. We make sure the 384 | blockquote has enough margin on the right and then put the equation 385 | number there. */ 386 | 387 | blockquote { 388 | margin: 0.5em 4em 0.5em 2em; 389 | text-indent: 0; 390 | } 391 | .eqno { 392 | text-align: right; 393 | float: right; 394 | width: 3em; 395 | margin: 0 -4em 0 0; 396 | font-weight: bold; 397 | /* background: silver; color: black; padding: 0.1em */ 398 | } 399 | 400 | table.equiv-table { border-spacing: 0; margin: 0.5em 0 } 401 | table.equiv-table th, table.equiv-table td { padding: 0.3em } 402 | table.equiv-table th { text-align: left } 403 | /* table.equiv-table th:first-child { text-align: right } */ 404 | table.equiv-table td, table.equiv-table th { border-bottom: thin solid #666 } 405 | table.equiv-table { border-bottom: hidden } 406 | table.equiv-table { empty-cells: show } 407 | table.equiv-table caption { margin: 0.5em 0 0 0 } 408 | 409 | /* Style for table of properties */ 410 | table.proptable { 411 | font-size: small; 412 | border-collapse: collapse; 413 | border-spacing: 0; 414 | text-align: left; 415 | margin: 1em 0; 416 | } 417 | 418 | table.proptable td, table.proptable th { 419 | padding: 0.4em; 420 | text-align: center; 421 | } 422 | 423 | table.proptable tr:hover td { 424 | background: #DEF; 425 | } 426 | 427 | 428 | /* Style for table that defines a property or a descriptor */ 429 | table.propdef, table.propdef-extra, table.descdef, table.definition-table { 430 | border-spacing: 0; 431 | padding: 0 1em 0.5em; 432 | width: 100%; 433 | table-layout: fixed; 434 | background: #DEF; 435 | margin: 1.2em 0; 436 | border-left: 0.5em solid #8CCBF2; 437 | } 438 | 439 | table.propdef td, table.propdef-extra td, table.descdef td, table.definition-table td, 440 | table.propdef th, table.propdef-extra th, table.descdef th, table.definition-table th { 441 | padding: 0.5em; 442 | vertical-align: baseline; 443 | border-bottom: 1px solid #bbd7e9; 444 | } 445 | /* 446 | table.propdef dfn, table.propdef-extra dfn, table.descdef dfn { 447 | font-weight: bold; 448 | font-style: normal 449 | } 450 | */ 451 | 452 | table.propdef td:first-child, 453 | table.propdef-extra td:first-child, 454 | table.descdef td:first-child, 455 | table.definition-table td:first-child, 456 | table.propdef th:first-child, 457 | table.propdef-extra th:first-child, 458 | table.descdef th:first-child, 459 | table.definition-table th:first-child { 460 | font-style: italic; 461 | font-weight: normal; 462 | width: 8.3em; 463 | padding-left: 1em; 464 | } 465 | table.propdef td[colspan]:first-child, 466 | table.propdef-extra td[colspan]:first-child, 467 | table.descdef td[colspan]:first-child, 468 | table.definition-table td[colspan]:first-child, 469 | table.propdef th[colspan]:first-child, 470 | table.propdef-extra th[colspan]:first-child, 471 | table.descdef th[colspan]:first-child, 472 | table.definition-table th[colspan]:first-child { 473 | font-style: inherit 474 | } 475 | table.propdef tr:first-child, 476 | table.propdef-extra tr:first-child, 477 | table.descdef tr:first-child, 478 | table.definition-table tr:first-child { 479 | 480 | } 481 | 482 | table.propdef > tbody > tr:last-child th, 483 | table.propdef-extra > tbody > tr:last-child th, 484 | table.descdef > tbody > tr:last-child th, 485 | table.definition-table > tbody > tr:last-child th, 486 | table.propdef > tbody > tr:last-child td, 487 | table.propdef-extra > tbody > tr:last-child td, 488 | table.descdef > tbody > tr:last-child td, 489 | table.definition-table > tbody > tr:last-child td { 490 | border-bottom: 0; 491 | } 492 | 493 | table.propdef tr:first-child th, 494 | table.propdef-extra tr:first-child th, 495 | table.descdef tr:first-child th, 496 | table.definition-table tr:first-child th, 497 | table.propdef tr:first-child td, 498 | table.propdef-extra tr:first-child td, 499 | table.descdef tr:first-child td, 500 | table.definition-table tr:first-child td { 501 | padding-top: 1em; 502 | } 503 | 504 | /* For when values are extra-complex and need formatting for readability */ 505 | table td.pre { 506 | white-space: pre-wrap; 507 | } 508 | 509 | /* A footnote at the bottom of a propdef */ 510 | table.propdef td.footnote, 511 | table.propdef-extra td.footnote, 512 | table.descdef td.footnote, 513 | table.definition-table td.footnote { 514 | padding-top: 0.6em; 515 | width: auto 516 | } 517 | table.propdef td.footnote:before, 518 | table.propdef-extra td.footnote:before, 519 | table.descdef td.footnote:before, 520 | table.definition-table td.footnote:before { 521 | content: " "; 522 | display: block; 523 | height: 0.6em; 524 | width: 4em; 525 | border-top: thin solid; 526 | } 527 | 528 | /* The link in the first column in the property table (formerly a TD) */ 529 | table.proptable td .property, 530 | table.proptable th .property { 531 | display: block; 532 | text-align: left; 533 | font-weight: bold; 534 | } 535 | 536 | 537 | /* Styling for IDL fragments */ 538 | 539 | pre.idl { 540 | padding: .5em 1em; 541 | background: #DEF; 542 | margin: 1.2em 0; 543 | border-left: 0.5em solid #8CCBF2; 544 | } 545 | pre.idl :link, pre.idl :visited { 546 | color:inherit; 547 | background:transparent; 548 | } 549 | 550 | 551 | /* CSS modules typically don't use MUST, SHOULD etc. from RFC 2119, 552 | or, if they do, they don't put them in uppercase. But the following 553 | class is provided in case a spec wants to use RFC 2119 terms in 554 | uppercase in the source. */ 555 | 556 | em.rfc2119 { 557 | text-transform: lowercase; 558 | font-variant: small-caps; 559 | font-style: normal 560 | } 561 | 562 | /* In Profile specs, a table of required features: */ 563 | 564 | table.features th { 565 | background: #00589f; 566 | color: #fff; 567 | text-align: left; 568 | padding: 0.2em 0.2em 0.2em 0.5em; 569 | } 570 | table.features td { 571 | vertical-align: top; 572 | border-bottom: 1px solid #ccc; 573 | padding: 0.3em 0.3em 0.3em 0.7em; 574 | } 575 | 576 | 577 | /* Style for data tables (and properly marked-up proptables) */ 578 | 579 | .data, .proptable { 580 | margin: 1em auto; 581 | border-collapse: collapse; 582 | width: 100%; 583 | border: hidden; 584 | } 585 | .data { 586 | text-align: center; 587 | width: auto; 588 | } 589 | .data caption { 590 | width: 100%; 591 | } 592 | 593 | .data td, .data th, 594 | .proptable td, .proptable th { 595 | padding: 0.5em; 596 | border-width: 1px; 597 | border-color: silver; 598 | border-top-style: solid; 599 | } 600 | 601 | .data thead td:empty { 602 | padding: 0; 603 | border: 0; 604 | } 605 | 606 | .data thead th[scope="row"], 607 | .proptable thead th[scope="row"] { 608 | text-align: right; 609 | color: inherit; 610 | } 611 | 612 | .data thead, 613 | .proptable thead, 614 | .data tbody, 615 | .proptable tbody { 616 | color: inherit; 617 | border-bottom: 2px solid; 618 | } 619 | 620 | .data colgroup { 621 | border-left: 2px solid; 622 | } 623 | 624 | .data tbody th:first-child, 625 | .proptable tbody th:first-child , 626 | .data tbody td[scope="row"]:first-child, 627 | .proptable tbody td[scope="row"]:first-child { 628 | text-align: right; 629 | color: inherit; 630 | border-right: 2px solid; 631 | border-top: 1px solid silver; 632 | padding-right: 1em; 633 | } 634 | .data.define td:last-child { 635 | text-align: left; 636 | } 637 | 638 | .data tbody th[rowspan], 639 | .proptable tbody th[rowspan], 640 | .data tbody td[rowspan], 641 | .proptable tbody td[rowspan]{ 642 | border-left: 1px solid silver; 643 | } 644 | 645 | .data tbody th[rowspan]:first-child, 646 | .proptable tbody th[rowspan]:first-child, 647 | .data tbody td[rowspan]:first-child, 648 | .proptable tbody td[rowspan]:first-child{ 649 | border-left: 0; 650 | border-right: 1px solid silver; 651 | } 652 | 653 | .complex.data th, 654 | .complex.data td { 655 | border: 1px solid silver; 656 | } 657 | 658 | .data td.long { 659 | vertical-align: baseline; 660 | text-align: left; 661 | } 662 | 663 | .data img { 664 | vertical-align: middle; 665 | } 666 | 667 | table.propdef { 668 | table-layout: auto; 669 | } 670 | .propdef th { 671 | font-style: italic; 672 | font-weight: normal; 673 | text-align: left; 674 | width: 3em; 675 | } 676 | dt dfn code { 677 | font-size: inherit; 678 | } 679 | 680 | /* Style for switch/case
s */ 681 | dl.switch { 682 | padding-left: 2em; 683 | } 684 | dl.switch > dt { 685 | text-indent: -1.5em; 686 | } 687 | dl.switch > dt:before { 688 | content: '\21AA'; 689 | padding: 0 0.5em 0 0; 690 | display: inline-block; 691 | width: 1em; 692 | text-align: right; 693 | line-height: 0.5em; 694 | } 695 | 696 | 697 | /* Style for At Risk features (intended as editorial aid, not intended for publishing) */ 698 | .atrisk::before { 699 | position: absolute; 700 | margin-left: -5em; 701 | margin-top: -2px; 702 | padding: 4px; 703 | border: 1px solid; 704 | content: 'At risk'; 705 | font-size: small; 706 | background-color: white; 707 | color: gray; 708 | border-radius: 1em; 709 | text-align: center; 710 | } 711 | 712 | .toc .atrisk::before { content:none } 713 | 714 | 715 | /* This is mostly to make the list inside the CR exit criteria more compact. */ 716 | ol.inline, ol.inline li {display: inline; padding: 0; margin: 0} 717 | ol.inline {counter-reset: list-item} 718 | ol.inline li {counter-increment: list-item} 719 | ol.inline li:before {content: "(" counter(list-item) ") "; font-weight: bold} 720 | 721 | /* This styles the obsoletion notice on some of our older/abandoned specs. */ 722 | details.annoying-warning[open] { 723 | background: #fdd; 724 | color: red; 725 | font-weight: bold; 726 | text-align: center; 727 | padding: .5em; 728 | border: thick solid red; 729 | border-radius: 1em; 730 | position: fixed; 731 | left: 1em; 732 | right: 1em; 733 | bottom: 1em; 734 | z-index: 1000; 735 | } 736 | 737 | details.annoying-warning:not([open]) > summary { 738 | background: #fdd; 739 | color: red; 740 | font-weight: bold; 741 | text-align: center; 742 | padding: .5em; 743 | } 744 | -------------------------------------------------------------------------------- /index.src.html: -------------------------------------------------------------------------------- 1 |

Referrer Policy

2 | 
   3 | Status: ED
   4 | ED: https://w3c.github.io/webappsec-referrer-policy/
   5 | Shortname: REFERRER-POLICY
   6 | TR: http://www.w3.org/TR/referrer-policy/
   7 | Level: none
   8 | Editor: Dominic Farolino 102763, Google Inc., domfarolino@gmail.com
   9 | Former Editor: Emily Stark 76989, Google Inc., estark@google.com
  10 | Former Editor: Jochen Eisinger 49402, Google Inc., eisinger@google.com
  11 | Group: webappsec
  12 | Abstract: This document describes how an author can set a referrer policy for documents they create, and the impact of such a policy on the Referer HTTP header for outgoing requests and navigations.
  13 | Version History: https://github.com/w3c/webappsec-referrer-policy/commits/main/index.src.html
  14 | Indent: 2
  15 | Ignored Vars: requestURL
  16 | Repository: w3c/webappsec-referrer-policy
  17 | !Tests: web-platform-tests referrer-policy/ (ongoing work)
  18 |
19 | 20 | 
  21 | spec: CSSOM-1; urlPrefix: https://drafts.csswg.org/cssom-1/
  22 |   type: dfn
  23 |     text: CSS declaration block
  24 |     text: location; url: concept-css-style-sheet-location
  25 |     text: owner node; for: CSSStyleDeclaration; url: cssstyledeclaration-owner-node
  26 |     text: owner node; for: CSSStyleSheet; url: concept-css-style-sheet-owner-node
  27 | spec: HTML; urlPrefix: https://html.spec.whatwg.org/multipage/
  28 |   type: dfn
  29 |     urlPrefix: semantics.html
  30 |       text: pragma directives
  31 |       text: noreferrer; url: link-type-noreferrer
  32 |       text: referrer; url: meta-referrer; for: meta
  33 |     urlPrefix: embedded-content.html
  34 |       text: an iframe srcdoc document
  35 |       text: relevant mutation; url: relevant-mutations
  36 |     urlPrefix: browsers.html
  37 |       text: opaque origin; url: concept-origin-opaque
  38 |       text: active document
  39 |       text: associated Document; url: concept-document-window
  40 |       text: parse a sandboxing directive
  41 |       text: forced sandboxing flag set
  42 |       text: auxiliary browsing context
  43 |       text: parent browsing context
  44 |       text: ancestor browsing context
  45 |       text: browsing context container
  46 |       text: child browsing context
  47 |       text: creating a new Document object
  48 |       text: navigation; url: navigate
  49 |       text: nested browsing context
  50 |       text: nested through; url: browsing-context-nested-through
  51 |       text: opener browsing context
  52 |       text: plugin document
  53 |       text: sandboxed origin browsing context flag
  54 |       text: sandboxing flag set
  55 |       text: top-level browsing context
  56 |       text: browsing context
  57 |     urlPrefix: infrastructure.html
  58 |       text: ascii case-insensitive match; url: ascii-case-insensitive
  59 |       text: document base url
  60 |       text: plugin
  61 |       text: reflect
  62 |       text: securityerror
  63 |       text: mime type
  64 |       text: strictly split a string
  65 |       text: skip whitespace
  66 |       text: collect a sequence of characters
  67 |       text: space characters
  68 |       text: split a string on spaces
  69 |       text: strip leading and trailing whitespace
  70 |       text: firing; url: concept-event-fire
  71 |       text: reflect
  72 |       text: limited to only known values
  73 |       text: referrer policy attribute
  74 |     urlPrefix: webappapis.html
  75 |       text: queue a task
  76 |       text: task source
  77 |       text: tasks; url: concept-task
  78 |       text: environment settings object
  79 |       text: responsible browsing context
  80 |       text: global object; for: environment settings object; url: concept-settings-object-global
  81 |       text: creation URL
  82 |     urlPrefix: workers.html
  83 |       text: running a worker; url: run-a-worker
  84 |     urlPrefix: dom.html
  85 |       text: style attribute; url: the-style-attribute
  86 |     urlPrefix: rendering.html
  87 |       text: presentational hints
  88 | 
  89 |   type: interface
  90 |     urlPrefix: dom.html
  91 |       text: Document
  92 |   type: element-attr
  93 |     urlPrefix: semantics.html
  94 |       text: name; for: meta; url: attr-meta-name
  95 |       text: referrerpolicy; for: a; url: #attr-hyperlink-referrerpolicy
  96 |       text: referrerpolicy; for: link; url: attr-link-referrerpolicy
  97 | spec: SECURE-CONTEXTS; urlPrefix: https://w3c.github.io/webappsec-secure-contexts
  98 |   type: dfn
  99 |     text: potentially trustworthy URL url: is-url-trustworthy
 100 | spec: RFC5234; urlPrefix: https://tools.ietf.org/html/rfc5234
 101 |   type: grammar
 102 |     text: ALPHA; url: appendix-B.1
 103 | spec: RFC9110; urlPrefix: https://httpwg.org/specs/rfc9110.html
 104 |   type: dfn
 105 |     text: referer; url: rfc.section.10.1.3
 106 | spec: RFC2616; urlPrefix: https://tools.ietf.org/html/rfc7231
 107 |   type: dfn
 108 |     text: redirection 3xx; url: section-6.4
 109 |
110 | 111 | 
 112 | spec: html; type: element; text: link
 113 | spec: html; type: element; text: a
 114 | spec: html; type: element; text: script
 115 | spec: html; type: element; text: meta
 116 | spec: html; type: interface; text: Window
 117 |
118 | 119 | 128 |
129 |

Introduction

130 | 131 | This section is not normative. 132 | 133 | Requests made from a document, and for navigations away from that document 134 | are associated with a Referer header. While the header 135 | can be suppressed for links with the noreferrer link 136 | type, authors might wish to control the Referer header 137 | more directly for a number of reasons: 138 | 139 |

Privacy

140 | 141 | A social networking site has a profile page for each of its users, and users 142 | add hyperlinks from their profile page to their favorite bands. The social 143 | networking site might not wish to leak the user's profile URL to the band web 144 | sites when other users follow those hyperlinks (because the profile URLs might 145 | reveal the identity of the owner of the profile). 146 | 147 | Some social networking sites, however, might wish to inform the band web sites 148 | that the links originated from the social networking site but not reveal which 149 | specific user's profile contained the links. 150 | 151 |

Security

152 | 153 | A web application uses HTTPS and a URL-based session identifier. The web 154 | application might wish to link to HTTPS resources on other web sites without 155 | leaking the user's session identifier in the URL. 156 | 157 | Alternatively, a web application may use URLs which themselves grant some 158 | capability. Controlling the referrer can help prevent these capability URLs 159 | from leaking via referrer headers. [[CAPABILITY-URLS]] 160 | 161 | Note that there are other ways for capability URLs to leak, and controlling 162 | the referrer is not enough to control all those potential leaks. 163 | 164 |

Trackback

165 | 166 | A blog hosted over HTTPS might wish to link to a blog hosted over HTTP and 167 | receive trackback links. 168 | 169 |
170 | 171 | 180 |
181 |

Key Concepts and Terminology

182 | 183 |
184 |
185 | referrer policy 186 |
187 |
188 | A referrer policy modifies the algorithm used to populate the 189 | Referer header when fetching subresources, 190 | prefetching, or performing navigations. This document defines the various 191 | behaviors for each referrer policy. 192 | 193 | Every environment settings object has an algorithm for obtaining a 194 | referrer policy, which is used by default for all requests 195 | with that environment settings object as their client. 196 |
197 | 198 |
same-origin-referrer request
199 |
200 | A {{Request}} request is a same-origin-referrer request if the 201 | origin of request's referrerURL and the origin 202 | of request's current URL are the same. 203 |
204 | 205 |
cross-origin-referrer request
206 |
207 | A {{Request}} is a cross-origin-referrer request if it is 208 | not a same-origin-referrer request. 209 |
210 |
211 |
212 | 213 |
214 |

Referrer Policies

215 | 216 | A referrer policy 217 | is the empty string, "no-referrer", 218 | "no-referrer-when-downgrade", "same-origin", 219 | "origin", "strict-origin", 220 | "origin-when-cross-origin", 221 | "strict-origin-when-cross-origin", or 222 | "unsafe-url". 223 | 224 | 
 225 |     enum ReferrerPolicy {
 226 |       "",
 227 |       "no-referrer",
 228 |       "no-referrer-when-downgrade",
 229 |       "same-origin",
 230 |       "origin",
 231 |       "strict-origin",
 232 |       "origin-when-cross-origin",
 233 |       "strict-origin-when-cross-origin",
 234 |       "unsafe-url"
 235 |     };
 236 |
237 | 238 | Each possible referrer policy is explained below. A detailed 239 | algorithm for evaluating their effect is given in the 240 | and 241 | sections. 242 | 243 | Note: The referrer policy for an environment settings object provides a 244 | default baseline policy for requests when that environment settings 245 | object is used as a request client. This policy may be tightened 246 | for specific requests via mechanisms like the noreferrer 247 | link type. 248 | 249 | The default referrer policy is "strict-origin-when-cross-origin". 250 | 251 |

"no-referrer"

252 | 253 | The simplest policy is "no-referrer", which specifies 254 | that no referrer information is to be sent along with requests to any 255 | origin. The header Referer will be omitted entirely. 256 | 257 |
258 | If a document at https://example.com/page.html sets a policy of 259 | "no-referrer", then navigations to 260 | https://example.com/ (or any other URL) would send no 261 | Referer header. 262 |
263 | 264 |

"no-referrer-when-downgrade"

265 | 266 | The "no-referrer-when-downgrade" policy sends a request's full 267 | referrerURL stripped for use as a referrer for requests: 268 | 269 | 274 | 275 | Requests whose referrerURL is a potentially trustworthy URL and whose 276 | current URL is a non-potentially trustworthy URL on the other hand, will 277 | contain no referrer information. A Referer HTTP header will not be sent. 278 | 279 |
280 | If a document at https://example.com/page.html sets a policy of 281 | "no-referrer-when-downgrade", then navigations to 282 | https://not.example.com/ would send a 283 | Referer HTTP header with a value of 284 | https://example.com/page.html, as neither resource's origin is a 285 | non-potentially trustworthy URL. 286 | 287 | Navigations from that same page to 288 | http://not.example.com/ would send no 289 | Referer header. 290 |
291 | 292 |

"same-origin"

293 | 294 | The "same-origin" policy specifies that a request's full referrerURL is 295 | sent as referrer information when making same-origin-referrer requests. 296 | 297 | Cross-origin-referrer requests, on the other hand, will contain no 298 | referrer information. A Referer HTTP header will not be 299 | sent. 300 | 301 |
302 | If a document at https://example.com/page.html sets a policy of 303 | "same-origin", then navigations to 304 | https://example.com/not-page.html would send a 305 | Referer header with a value of 306 | https://example.com/page.html. 307 | 308 | Navigations from that same page to 309 | https://not.example.com/ would send no 310 | Referer header. 311 |
312 | 313 |
314 | If a document at https://example.com/page.html sets a policy of 315 | "same-origin", and fetches a module script at 316 | https://script.example.com, which then fetches a descendant script 317 | at https://example.com/descendant.js, the request for the descendant 318 | script would send no Referer header. 319 | 320 | This is because the descendant script request's current URL is 321 | https://example.com/descendant.js, while its referrerURL is 322 | https://script.example.com, making the request 323 | cross-origin-referrer. 324 |
325 | 326 |

"origin"

327 | 328 | The "origin" policy specifies that only the 329 | ASCII serialization of the request's 330 | referrerURL is sent as referrer information when making both same-origin-referrer 331 | requests and cross-origin-referrer requests. 332 | 333 | Note: The serialization of an origin looks like https://example.com. 334 | To ensure that a valid URL is sent in the `Referer` header, user 335 | agents will append a U+002F SOLIDUS ("/") character to the origin 336 | (e.g. https://example.com/). 337 | 338 | Note: The "origin" policy allows the origin of HTTPS 339 | referrers to be sent over the network as part of unencrypted HTTP requests. 340 | The "strict-origin" policy addresses this concern. 341 | 342 |
343 | If a document at https://example.com/page.html sets a policy of 344 | "origin", then navigations to any 345 | origin would send a Referer header with a value 346 | of https://example.com/, even to URLs that are not 347 | potentially trustworthy URL. 348 |
349 | 350 |
351 | If a document at https://example.com/page.html sets a policy of 352 | "origin", and fetches a module script at 353 | https://script.example.com, which fetches a descendant script at 354 | https://descendant.example.com, the request for the descendant script 355 | will send a Referer header with a value of 356 | https://script.example.com/. 357 |
358 | 359 |

"strict-origin"

360 | 361 | The "strict-origin" policy sends the 362 | ASCII serialization of the origin of the 363 | referrerURL for requests: 364 | 365 | 370 | 371 | Requests whose referrerURL is a potentially trustworthy URL and whose 372 | current URL is a non-potentially trustworthy URL on the other hand, will 373 | contain no referrer information. A Referer HTTP header will not be sent. 374 | 375 |
376 | If a document at https://example.com/page.html sets a policy of 377 | "strict-origin", then navigations to 378 | https://not.example.com would send a 379 | Referer header with a value of 380 | https://example.com/. 381 | 382 | Navigations from that same page to 383 | http://not.example.com would send no 384 | Referer header. 385 |
386 | 387 |
388 | If a document at http://example.com/page.html sets a policy of 389 | "strict-origin", then navigations to 390 | http://not.example.com or 391 | https://example.com would send a 392 | Referer header with a value of 393 | http://example.com/. 394 |
395 | 396 |
397 | If a document at http://example.com/page.html sets a policy of 398 | "strict-origin", and fetches a module script at 399 | https://script.example.com, which then fetches a 400 | descendant script at http://descendant.example.com, 401 | the request to the descendant script would not send a Referrer 402 | header. 403 |
404 | 405 |

"origin-when-cross-origin"

406 | 407 | The "origin-when-cross-origin" policy specifies that a request's full 408 | referrerURL is sent as referrer information when making same-origin-referrer requests, 409 | and only the ASCII serialization of the 410 | origin of the request's referrerURL is sent as referrer information when making 411 | cross-origin-referrer requests. 412 | 413 | Note: For the "origin-when-cross-origin" policy, we also 414 | consider protocol upgrades, e.g. requests from 415 | http://example.com/ to https://example.com/, to be 416 | cross-origin-referrer requests. 417 | 418 | Note: The "origin-when-cross-origin" policy allows the 419 | origin of HTTPS referrers to be sent over the network as part of unencrypted 420 | HTTP requests. The "strict-origin-when-cross-origin" policy 421 | addresses this concern. 422 | 423 |
424 | If a document at https://example.com/page.html sets a policy of 425 | "origin-when-cross-origin", then navigations to 426 | https://example.com/not-page.html would send a 427 | Referer header with a value of 428 | https://example.com/page.html. 429 | 430 | Navigations from that same page to https://not.example.com/ 431 | would send a Referer header with a value of 432 | https://example.com/, even to URLs that are not 433 | potentially trustworthy URLs. 434 |
435 | 436 |
437 | If a document at https://example-1.com sets a policy of 438 | "origin-when-cross-origin", and fetches a module script at 439 | https://example-2.com/module.js, which then fetches a descendant script at 440 | https://example-1.com/descendant.js, the request to the descendant script would 441 | send a Referer header with a value of https://example-2.com/. 442 |
443 | 444 |
445 | If a document at https://example-1.com sets a policy of 446 | "origin-when-cross-origin", and fetches a module script at 447 | https://example-2.com/module.js, which then fetches a descendant script at 448 | https://example-2.com/descendant.js, the request to the descendant script would 449 | send a Referer header with a value of https://example-2.com/module.js. 450 |
451 | 452 | 453 |

"strict-origin-when-cross-origin"

454 | 455 | The "strict-origin-when-cross-origin" policy specifies that a request's full 456 | referrerURL is sent as referrer information when making same-origin-referrer requests, 457 | and only the ASCII serialization of the 458 | origin of the request's referrerURL when making 459 | cross-origin-referrer requests: 460 | 461 | 466 | 467 | Requests whose referrerURL is a potentially trustworthy URL and whose 468 | current URL is a non-potentially trustworthy URL on the other hand, 469 | will contain no referrer information. A Referer HTTP header will not be sent. 470 | 471 |
472 | If a document at https://example.com/page.html sets a policy of 473 | "strict-origin-when-cross-origin", then navigations to 474 | https://example.com/not-page.html would send a 475 | Referer header with a value of 476 | https://example.com/page.html. 477 | 478 | Navigations from that same page to https://not.example.com/ 479 | would send a Referer header with a value of 480 | https://example.com/. 481 | 482 | Navigations from that same page to 483 | http://not.example.com/ would send no 484 | Referer header. 485 |
486 | 487 |
488 | If a document at https://example.com/page.html sets a policy of 489 | "strict-origin-when-cross-origin", and fetches a module script 490 | at https://script.example.com which then fetches a descendant script at 491 | http://descendant.example.com, the request to the descendant 492 | script would send no Referer header. 493 |
494 | 495 | This policy is the user agent's default, and will be applied 496 | if no policy is otherwise specified. 497 | 498 |

"unsafe-url"

499 | 500 | The "unsafe-url" policy specifies that a request's full referrerURL is 501 | sent along for both same-origin-referrer requests and cross-origin-referrer requests. 502 | 503 |
504 | If a document at https://example.com/sekrit.html sets a policy 505 | of "unsafe-url", then navigations to 506 | http://not.example.com/ (and every other origin) would send a 507 | Referer HTTP header with a value of 508 | https://example.com/sekrit.html. 509 |
510 | 511 | Note: The policy's name doesn't lie; it is unsafe. This policy will leak 512 | origins and paths from secure resources to insecure origins. 513 | Carefully consider the impact of setting such a policy for potentially 514 | sensitive documents. 515 | 516 |

The empty string

517 | 518 | The empty string "" corresponds to no referrer policy, causing a 519 | fallback to a referrer policy defined elsewhere, or in the case where 520 | no such higher-level policy is available, falling back to the default referrer 521 | policy. This happens in Fetch's main fetch algorithm, for example. 522 | 523 |
524 | Given a HTML <{a}> element without any declared <{a/referrerpolicy}> 525 | attribute, its referrer policy is the empty string. Thus, navigation requests initiated by 526 | clicking on that <{a}> element will be sent with the <{a}> element's node document's policy container's referrer policy. If that 528 | {{Document}} has the empty string as its referrer policy, the [[#determine-requests-referrer]] 529 | algorithm will treat the empty string the same as 530 | "strict-origin-when-cross-origin". 531 |
532 | 533 |
534 | 535 |
536 |

Referrer Policy Delivery

537 | 538 | A request's referrer policy 539 | is delivered in one of five ways: 540 | 541 |
    542 |
  • 543 | Via the Referrer-Policy HTTP header (defined 544 | in [[#referrer-policy-header]]). 545 |
    • 546 |
  • 547 | Via a <{meta}> element with a <{meta/name}> of 548 | referrer. 549 |
    • 550 |
  • 551 | Via a referrerpolicy content attribute on an <{a}>, 552 | <{area}>, <{img}>, <{iframe}>, <{link}>, or <{script}> element. 553 |
    • 554 |
  • 555 | Via the noreferrer link relation on an <{a}>, or 556 | <{area}> element. 557 |
    • 558 |
  • 559 | Implicitly, via inheritance. 560 |
    • 561 |
562 | 563 |

Delivery via Referrer-Policy header

564 | 565 | The Referrer-Policy HTTP header 567 | specifies the referrer policy that the user agent applies when determining 568 | what referrer information should be included with requests made, and with 569 | browsing contexts created from the context of the protected 570 | resource. 571 | 572 | The syntax for the name and value of the header are described by the following 573 | ABNF grammar. ABNF is defined in [[!RFC5234]], and the #rule ABNF 574 | extension used below is defined in [[RFC9110#abnf.extension|Section 5.6.1]] of 575 | [[!RFC9110]]. 576 | 577 | 
 578 |     "Referrer-Policy:" 1#(policy-token / extension-token)
 579 |
580 | 
 581 |     policy-token = "no-referrer" / "no-referrer-when-downgrade" / "strict-origin" / "strict-origin-when-cross-origin" / "same-origin" / "origin" / "origin-when-cross-origin" / "unsafe-url"
 582 |     extension-token = 1*( ALPHA / "-" )
 583 |
584 | 585 | Note: The header name does not share the HTTP Referer header's misspelling. 586 | 587 | Note: The purpose of extension-token is so that 588 | browsers do not fail to parse the entire header field if it includes an 589 | unknown policy value. [[#unknown-policy-values]] describes in greater detail 590 | how new policy values can be deployed. 591 | 592 | Note: The quotes in the ABNF above are used to indicate literal strings. 593 | Referrer-Policy header values should not be quoted. 594 | 595 | [[#integration-with-fetch]] and [[#integration-with-html]] describe 596 | how the Referrer-Policy header is processed. 597 | 598 |
599 |

Usage

600 | 601 | This section is not normative. 602 | 603 | A protected resource can prevent referrer leakage by specifying 604 | no-referrer as the value of its 605 | Referrer-Policy header: 606 | 607 | 
 608 |       Referrer-Policy: no-referrer
 609 |
610 | 611 | This will cause all requests made from the protected resource's 612 | context to have an empty Referer [sic] header. 613 |
614 | 615 |
616 |

Delivery via <{meta}>

617 | 618 | This section is not normative. 619 | 620 | The HTML Standard defines the referrer 621 | keyword for the <{meta}> element, which allows setting the referrer 622 | policy via markup. 623 |
624 | 625 |
626 |

Delivery 627 | via a referrerpolicy content attribute

628 | 629 | This section is not normative. 630 | 631 | The HTML Standard defines the concept of referrer policy 632 | attributes which applies to several of its elements, for example: 633 | 634 | 

 635 |       <a href="http://example.com" referrerpolicy="origin">
 636 |
637 |
638 | 639 |
640 |

Referrer Policy Inheritance

642 | 643 | This section is not normative. 644 | 645 | Referrer policy is inherited following the inheritance mechanism of 646 | policy containers, as defined by HTML. 647 |
648 |
649 | 650 |
651 |

Integration with Fetch

652 | 653 | This section is not normative. 654 | 655 | The Fetch specification calls out to 656 | [[#set-requests-referrer-policy-on-redirect]] 657 | before [[fetch#http-redirect-fetch|Step 19 of the HTTP-redirect fetch]], so 658 | that a request's referrer policy can be updated before following a redirect. 659 | 660 | The Fetch specification calls out to [[#determine-requests-referrer]] 661 | as [[fetch#main-fetch|Step 8 of the Main fetch algorithm]], and uses the 662 | result to set the request's referrer property. Fetch 663 | is responsible for serializing the URL provided, and setting the 664 | `Referer` header on request. 665 |
666 | 667 |
668 |

Integration with HTML

669 | 670 | This section is not normative. 671 | 672 | The HTML Standard determines the referrer policy of any response 673 | received during navigation or while running a worker, and uses 674 | the result to set the resulting {{Document}}'s policy 675 | container's or {{WorkerGlobalScope}}'s policy 676 | container's referrer policy. 677 |
678 | 679 |
680 |

Integration with CSS

681 | 682 | The CSS Standard does not specify how it fetches resources referenced from 683 | stylesheets. However, implementations should be sure to set the 684 | referrer-related properties of any requests initiated by stylesheets 685 | as follows: 686 | 687 |
    688 |
  1. 689 | If a CSS style sheet is responsible for the request, 690 | and its location is non-null, 691 | set the referrer to its 692 | location, and the referrer 693 | policy to its referrer policy. 694 | 695 | Issue: This requires that CSS style sheets process `Referrer-Policy` 696 | headers, and store a referrer policy 697 | in the same way that Documents 698 | do. 699 |
    2. 700 | 701 |
  2. 702 | If a CSS style sheet with a null location is responsible 703 | for the request, set the referrer to its 704 | owner node's 705 | node document's URL, and the 706 | referrer policy to its 707 | owner node's 708 | node document's policy container's 709 | referrer policy. 710 |
    3. 711 | 712 |
  3. 713 | Otherwise, a CSS declaration block that was created by the 714 | embedder is responsible for the request - either from parsing of an 715 | element's style attribute, or to implement an presentational 716 | hint for an element. We assume that in this case the CSS 717 | declaration block's owner node 718 | points to that element, and set the referrer to the 719 | block's owner node's node 720 | document's URL, and the 721 | referrer policy to the block's 722 | owner node's node document's 723 | policy container's 724 | referrer policy. 725 |
    4. 726 |
727 | 728 | Note: Both the value of the request's referrer 729 | and referrer policy are set based on the values at the 730 | time a given request is created. If a document's referrer policy 731 | changes during its lifetime, the policy associated with inline stylesheet 732 | requests will also change. 733 |
734 | 735 |
736 |

Algorithms

737 | 738 |

739 | Parse a referrer policy from a Referrer-Policy header 740 |

741 | 742 | Given a response |response|, the following steps return a 743 | referrer policy according to |response|'s 744 | `Referrer-Policy` header: 745 | 746 |
    747 |
  1. 748 | Let |policy-tokens| be the result of extracting header list values given 749 | `Referrer-Policy` and |response|'s header list. 750 |
    2. 751 |
  2. 752 | Let |policy| be the empty string. 753 |
    3. 754 |
  3. 755 | For each |token| in |policy-tokens|, if |token| is a referrer 756 | policy and |token| is not the empty string, then set |policy| 757 | to |token|. 758 | 759 | Note: This algorithm loops over multiple policy values to allow 760 | deployment of new policy values with fallbacks for older user 761 | agents, as described in [[#unknown-policy-values]]. 762 |
    4. 763 |
  4. 764 | Return |policy|. 765 |
    5. 766 |
767 | 768 |

769 | Set |request|'s referrer policy on redirect 770 |

771 | 772 | Given a request |request| and a response |actualResponse|, 773 | this algorithm updates |request|'s referrer policy 774 | according to the Referrer-Policy header (if any) in |actualResponse|. 775 | 776 |
    777 |
  1. 778 | Let |policy| be the result of executing 779 | [[#parse-referrer-policy-from-header]] on |actualResponse|. 780 |
    2. 781 |
  2. If |policy| is not the empty string, then set |request|'s 782 | referrer policy to |policy|.
    3. 783 |
784 | 785 |

786 | Determine request's Referrer 787 |

788 | 789 | Given a request |request|, we can determine the correct 790 | referrer information to send by examining its referrer policy 791 | as detailed in the following steps, which return either no referrer or a URL: 792 | 793 |
    794 |
  1. 795 | Let policy be |request|'s referrer policy. 796 |
    2. 797 |
  2. 798 | Let environment be request's client. 799 |
    3. 800 |
  3. 801 | Switch on |request|'s referrer: 802 | 803 |
    804 |
    "client"
    805 |
    806 |
      807 |
    1. If |environment| is null, then return no referrer.
      2. 808 | 809 |
    2. 810 | If |environment|'s global 811 | object is a {{Window}} object, then 812 | 813 |
        814 |
      1. Let |document| be 815 | the associated Document of |environment|'s 816 | global object.
        2. 817 | 818 |
      2. If |document|'s origin is an opaque origin, 819 | return no referrer.
        3. 820 | 821 |
      3. While |document| is an iframe srcdoc 822 | document, let |document| be |document|'s browsing context's browsing context 824 | container's node document.
        4. 825 | 826 |
      4. Let |referrerSource| be |document|'s URL.
        5. 828 |
      829 |
      3. 830 | 831 |
    3. Otherwise, let |referrerSource| be |environment|'s creation 832 | URL.
      4. 833 |
    834 |
    835 | 836 |
    a URL
    837 |
    Let |referrerSource| be |request|'s referrer.
    838 |
    839 | 840 | Note: If request's referrer is 841 | "no-referrer", Fetch will not call into this algorithm. 842 |
    4. 843 | 844 |
  4. 845 | Let request's referrerURL be the result of stripping 846 | referrerSource for use as a referrer. 847 |
    5. 848 |
  5. 849 | Let referrerOrigin be the result of 850 | stripping referrerSource for use as a 851 | referrer, with the origin-only flag set to 852 | true. 853 |
    6. 854 |
  6. 855 | If the result of serializing referrerURL is a string whose 856 | length is greater than 4096, set referrerURL to 857 | referrerOrigin. 858 |
    7. 859 |
  7. 860 | The user agent MAY alter referrerURL or referrerOrigin at this point to 861 | enforce arbitrary policy considerations in the interests of minimizing data leakage. For 862 | example, the user agent could strip the URL down to an origin, modify its 863 | host, replace it with an empty string, etc. 864 |
    8. 865 |
  8. 866 | Execute the statements corresponding to the value of policy:
    867 | Note: If request's referrer policy is 868 | the empty string, Fetch will not call into this algorithm. 869 | 870 |
    871 |
    "no-referrer"
    872 |
    Return no referrer
    873 | 874 |
    "origin"
    875 |
    Return referrerOrigin
    876 | 877 |
    "unsafe-url"
    878 |
    Return referrerURL.
    879 | 880 |
    "strict-origin"
    881 |
    882 |
      883 |
    1. 884 | If referrerURL is a potentially trustworthy URL and request's 885 | current URL is not a potentially trustworthy URL, then 886 | return no referrer. 887 |
      2. 888 |
    2. Return |referrerOrigin|. 889 |
    890 |
    891 | 892 |
    "strict-origin-when-cross-origin"
    893 |
    894 |
      895 |
    1. 896 | If the origin of referrerURL and the origin of 897 | request's current URL are the 898 | same, then return referrerURL. 899 |
      2. 900 |
    2. 901 | If referrerURL is a potentially trustworthy URL and request's 902 | current URL is not a potentially trustworthy URL, then 903 | return no referrer. 904 |
      3. 905 |
    3. Return |referrerOrigin|. 906 |
    907 |
    908 | 909 |
    "same-origin"
    910 |
    911 |
      912 |
    1. 913 | If the origin of referrerURL and the origin of 914 | request's current URL are the 915 | same, then return referrerURL. 916 | 917 | Note: This same-origin check determines whether or not the request is 918 | same-origin-referrer. 919 |
      2. 920 |
    2. Return no referrer. 921 |
    922 |
    923 | 924 |
    "origin-when-cross-origin"
    925 |
    926 |
      927 |
    1. 928 | If the origin of referrerURL and the origin of 929 | request's current URL are the 930 | same, then return referrerURL. 931 |
      2. 932 |
    2. Return |referrerOrigin|. 933 |
    934 |
    935 | 936 |
    "no-referrer-when-downgrade"
    937 |
    938 |
      939 |
    1. 940 | If referrerURL is a potentially trustworthy URL and request's 941 | current URL is not a potentially trustworthy URL, then 942 | return no referrer. 943 |
      2. 944 |
    2. Return referrerURL. 945 |
    946 |
    947 |
    948 |
    9. 949 |
950 | 951 |

952 | Strip url for use as a referrer 953 |

954 | 955 | Certain portions of URLs must not be included when sending a URL as the value 956 | of a `Referer` header: a URLs fragment, username, and password 957 | components must be stripped from the URL before it's sent out. This 958 | algorithm accepts a origin-only flag, which defaults 959 | to false. If set to true, the algorithm will 960 | additionally remove the URL's path and query components, leaving only the 961 | scheme, host, and port. 962 | 963 |
    964 |
  1. Assert: url is a URL.
    2. 965 |
  2. 966 | If url's scheme is a local scheme, then 967 | return no referrer. 968 |
    3. 969 |
  3. 970 | Set url's username to the empty string. 971 |
    4. 972 |
  4. 973 | Set url's password to the empty string. 974 |
    5. 975 |
  5. 976 | Set url's fragment to null. 977 |
    6. 978 |
  6. 979 | If the origin-only flag is true, 980 | then: 981 | 982 |
      983 |
    1. 984 | Set url's path to « the empty string ». 985 |
      2. 986 |
    2. 987 | Set url's query to null. 988 |
      3. 989 |
    990 |
    7. 991 |
  7. 992 | Return url. 993 |
    8. 994 |
995 | 996 |
997 | 998 |
999 |

Privacy Considerations

1000 | 1001 |

User Controls

1002 | 1003 | Nothing in this specification should be interpreted as preventing user 1004 | agents from offering options to users which would change the information 1005 | sent out via a `Referer` header. For instance, user agents 1006 | MAY allow users to suppress the referrer header entirely, regardless of the 1007 | active referrer policy on a page. 1008 |
1009 | 1010 |
1011 |

Security Considerations

1012 | 1013 |

Information Leakage

1014 | 1015 | The referrer policies "origin", 1016 | "origin-when-cross-origin" and 1017 | "unsafe-url" might leak the origin and the URL of 1018 | a secure site respectively via insecure transport. 1019 | 1020 | Those three policies are included in the spec nevertheless to lower the friction 1021 | of sites adopting secure transport. 1022 | 1023 | Authors wanting to ensure that they do not leak any more information than 1024 | the default policy should instead use the policy states 1025 | "same-origin", "strict-origin", or 1026 | "no-referrer". 1027 | 1028 |

Downgrade to less strict policies

1029 | 1030 | The spec does not forbid downgrading to less strict policies, e.g., from 1031 | "no-referrer" to "unsafe-url". 1032 | 1033 | On the one hand, it is not clear which policy is more strict for all possible 1034 | pairs of policies: While "no-referrer-when-downgrade" will 1035 | not leak any information over insecure transport, and 1036 | "origin" will, the latter reveals less information 1037 | across cross-origin navigations. 1038 | 1039 | On the other hand, allowing for setting less strict policies enables authors 1040 | to define safe fallbacks as described in [[#unknown-policy-values]]. 1041 |
1042 | 1043 |
1044 |

Authoring Considerations

1045 | 1046 |

Unknown Policy Values

1047 | 1048 | As described in [[#parse-referrer-policy-from-header]] and in the 1049 | <{meta}> referrer algorithm, unknown 1050 | policy values will be ignored, and when multiple sources specify a 1051 | referrer policy, the value of the latest one will be used. This makes 1052 | it possible to deploy new policy values. 1053 | 1054 |
1055 | Suppose older user agents don't understand 1056 | the "unsafe-url" policy. A site can specify 1057 | an "origin" policy followed by an 1058 | "unsafe-url" policy: older user agents will ignore the 1059 | unknown "unsafe-url" value and use 1060 | "origin", while newer user agents will use 1061 | "unsafe-url" because it is the last to be processed. 1062 |
1063 | 1064 |
1065 | To specify multiple policy values in the Referrer-Policy header, a site can 1066 | send multiple Referrer-Policy headers: 1067 | 
1068 |       Referrer-Policy: no-referrer
1069 |       Referrer-Policy: unsafe-url
1070 |
1071 | or, equivalently, multiple comma-separated header values: 1072 | 
1073 |       Referrer-Policy: no-referrer,unsafe-url
1074 |
1075 |
1076 | 1077 | This behavior does not, however, apply to 1078 | the referrerpolicy attribute. Authors may dynamically set 1079 | and get the referrerpolicy attribute to detect whether a 1080 | particular policy value is supported. 1081 | 1082 |
1083 | 1084 | 1093 |
1094 |

Acknowledgements

1095 | 1096 | This specification is based in large part on Adam Barth and Jochen Eisinger's 1097 | Meta referrer 1098 | document. 1099 | 1100 | Francois 1101 | Marier contributed 1102 | the same-origin, strict-origin, 1103 | and strict-origin-when-cross-origin policies. 1104 |
1105 | -------------------------------------------------------------------------------- /published/2014-08-07-REFERRER-FPWD.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | Referrer Policy 4 | 5 | 6 | 7 | 8 |
9 |

12 |

13 |

Referrer Policy

14 |

W3C First Public Working Draft, 15 | 7 August 2014

16 |
17 |
This version: 18 |
http://www.w3.org/TR/2014/WD-referrer-policy-20140807/ 19 |
Latest version: 20 |
http://www.w3.org/TR/referrer-policy/ 21 |
Editor’s Draft: 22 |
https://w3c.github.io/webappsec/specs/referrer-policy/ 23 |
Version History: 24 |
https://github.com/w3c/webappsec/commits/master/specs/referrer-policy/index.src.html 25 |
Feedback: 26 |
public-webappsec@w3.org 27 | with subject line 28 | “[REFERRER] … message topic …”(archives) 29 |
Editors: 30 |
(Google Inc.) 31 |
(Google Inc.) 32 |
33 |
34 |
35 |

Copyright © 2014 36 | W3C® 37 | (MIT, 38 | ERCIM, 39 | Keio, Beihang), 40 | 41 | All Rights Reserved. 42 | 43 | W3C liability, 44 | trademark and 45 | 46 | document use 47 | rules apply. 48 |

49 |
50 |
51 | 52 |

Abstract

53 |

This document describes how an author can set a referrer policy for documents they create, and the impact of such a policy on the referer HTTP header for outgoing requests and navigations.

54 | 55 | 56 | 57 |
58 | 59 |

Status of this document

60 |

61 | This section describes the status of this document at the time of 62 | its publication. Other documents may supersede this document. A list of 63 | current W3C publications and the latest revision of this technical report 64 | can be found in the W3C technical reports 65 | index at http://www.w3.org/TR/. 66 | 67 |

68 | This document was published by the 69 | Web Application Security Working Group 70 | as a Working Draft. This document is intended to become a W3C Recommendation. 71 | 72 |

73 | The (archived) public mailing list 74 | public-webappsec@w3.org 75 | (see instructions) 76 | is preferred for discussion of this specification. 77 | When sending e-mail, 78 | please put the text “REFERRER” in the subject, 79 | preferably like this: 80 | “[REFERRER] …summary of comment…” 81 | 82 |

83 | This document is a First Public Working Draft. 84 | 85 |

86 | Publication as a First Public Working Draft does not imply endorsement by the W3C 87 | Membership. This is a draft document and may be updated, replaced or 88 | obsoleted by other documents at any time. It is inappropriate to cite this 89 | document as other than work in progress. 90 | 91 |

92 | This document was produced by the 93 | Web Application Security Working Group. 94 | 95 |

96 | This document was produced by a group operating under 97 | the 5 February 2004 W3C Patent Policy. 98 | W3C maintains a public list of any patent disclosures 99 | made in connection with the deliverables of the group; 100 | that page also includes instructions for disclosing a patent. 101 | An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) 102 | must disclose the information in accordance with section 6 of the W3C Patent Policy. 103 |

104 |
105 | 106 |

Table of Contents

107 |
149 | 150 | 151 | 152 | 153 |
154 |

1 Introduction

155 | 156 |

This section is not normative.

157 | 158 |

Requests made from a document, and for navigations away from that document 159 | are associated with a referer header. While the header 160 | can be suppressed for links with the noreferrer link 161 | type, authors might wish to control the referer header 162 | more directly for a number of reasons:

163 | 164 |

1.1 Privacy

165 | 166 |

A social networking site has a profile page for each of its users, and users 167 | add hyperlinks from their profile page to their favorite bands. The social 168 | networking site might not wish to leak the user’s profile URL to the band web 169 | sites when other users follow those hyperlinks (because the profile URLs might 170 | reveal the identity of the owner of the profile).

171 | 172 |

Some social networking sites, however, might wish to inform the band web sites 173 | that the links originated from the social networking site but not reveal which 174 | specific user’s profile contained the links.

175 | 176 |

1.2 Security

177 | 178 |

A web application uses HTTPS and a URL-based session identifier. The web 179 | application might wish to link to HTTPS resources on other web sites without 180 | leaking the user’s session identifier in the URL.

181 | 182 |

Alternatively, a web application may use URLs which themselves grant some 183 | capability. Controlling the referrer can help prevent these capability URLs 184 | from leaking via referrer headers. [CAPABILITY-URLS]

185 | 186 |

1.3 Trackback

187 | 188 |

A blog hosted over HTTPS might wish to link to a blog hosted over HTTP and 189 | receive trackback links.

190 | 191 |
192 | 193 | 194 |
195 |

2 Key Concepts and Terminology

196 | 197 |

2.1 Terms defined by this specification

198 |
199 |
200 | referrer policy 201 |
202 |
203 | A referrer policy is a property of a JavaScript 204 | global environment that defines the algorithm used to populate the 205 | referer header when fetching subresources, 206 | prefetching, or performing navigations. 207 | 208 |

If no referrer policy is explicitly set for a global environment, 209 | then the value of the property is null. Otherwise, the value 210 | is whatever has been explicitly set, as explained in the 211 | §6.1 212 | Set environment’s referrer policy to policy. 213 | algorithm. 214 |

215 |
216 | 217 |

2.2 Terms defined by reference

218 |
219 |
Referer HTTP header field
220 |
221 | The "Referer" [sic] HTTP header field is sent along with 222 | HTTP requests, and informs the server where the reference for the 223 | requested resource was found. It is specified in 224 | Section 5.5.2 225 | of HTTP/1.1 -- Semantics and Content [RFC7231] 226 |
227 | 228 |
origin
229 |
230 | An origin defines the scope of authority or privilege under which a 231 | resource operates. It is defined in detail in the Origin specification. 232 | [RFC6454] 233 |
234 | 235 |
ASCII serialization of an origin
236 |
237 | This algorithm is defined in 238 | Section 6.2 239 | of the Origin specification. [RFC6454] 240 |
241 | 242 |
same-origin request
243 |
244 | A request is a same-origin request if the 245 | request’s origin and the origin of request’s 246 | url are "the same", as defined by 247 | Section 5 248 | of the Origin specification. [RFC6454] 249 |
250 | 251 |
cross-origin request
252 |
253 | A request is a cross-origin request if it is 254 | not same-origin. 255 |
256 | 257 |
fetch
258 |
259 | "fetching" is the process by which a user agent requests resources, and 260 | delivers responses. It is defined in detail in the Fetch living standard. 261 | [FETCH] 262 |
263 | 264 |
request
265 |
request client
266 |
request context
267 |
268 | These terms are defined in 269 | Section 2.2 of the 270 | Fetch living standard. [FETCH] 271 |
272 | 273 |
a priori insecure origin
274 |
275 | This term is defined in 276 | Section 2.1 277 | of the Mixed Content specification. [MIX]. 278 |
279 | 280 |
JavaScript global environment
281 |
282 | This term is defined in Section 283 | 2.2.2 of the HTML5 specification. [HTML5] 284 |
285 | 286 |
global object
287 |
288 | This term is defined in the ECMAScript specification. [ECMA-262] 289 |
290 | 291 |
document environment
292 |
worker environment
293 |
294 | These terms are defined in 295 | Section 6.1.3.1 of the 296 | HTML5 specification. [[!!HTML5]] 297 |
298 | 299 |
API referrer source
300 |
301 | This term is defined in 302 | Section 8.1.3.1 of the 303 | HTML5 specification. [HTML5] 304 |
305 | 306 |
Entry settings object
307 |
308 | This term is defined in 309 | Section 8.1.3.3 of the 310 | HTML5 specification. [HTML5] 311 |
312 | 313 |
TLS-protected
314 |
315 | This term is defined in 316 | Section 317 | 5.2 of "Web Security Context: User Interface Guidelines". [WSC-UI]. 318 |
319 | 320 |
relative scheme
321 |
322 | The set of relative schemes is defined in 323 | Section 5 of the 324 | URL specification. [URL] 325 |
326 | 327 |
runs a worker algorithm
328 |
329 | This algorithm is 330 | defined in the Web 331 | Workers spec. [WORKERS] 332 |
333 |
334 |
335 | 336 |
337 |

3 Referrer Policy States

338 | 339 |

Every global environment has a referrer policy which governs 340 | the referrer information sent along with requests made for subresources, and 341 | for navigations. The policy will be null if no policy has 342 | been set, otherwise it will be one of the following five values: 343 | None, None when downgrade, 344 | Origin Only, Origin when cross-origin, 345 | and Unsafe URL. Each is explained below, and a detailed 346 | algorithm for evaluating their effect is given in the 347 | §5 Integration with Fetch and 348 | §6 Algorithms sections:

349 | 350 |

Note: The referrer policy for a global environment provides a default 351 | baseline policy for requests. This policy may be tightened for specific 352 | requests via mechanisms like the noreferrer link type.

353 | 354 |

3.1 None

355 | 356 |

The simplest policy is None, which specifies that no referrer 357 | information is to be sent along with requests made from a particular global 358 | environment to any origin. The header will be omitted entirely.

359 | 360 |
361 | If a document at https://example.com/page.html sets a policy of 362 | None, then navigations to https://example.com/ 363 | (or any other URL) would send no referer header. 364 |
365 | 366 |

3.2 None When Downgrade

367 | 368 |

The None When Downgrade policy sends a full URL along with requests 369 | from TLS-protected global environments to a non-a 370 | priori insecure origin, and requests from global environments 371 | which are not TLS-protected to any origin.

372 | 373 |

Requests from TLS-protected global environments to a 374 | priori insecure origins, on the other hand, will contain no referrer 375 | information. A referer will not be sent.

376 | 377 |
378 | If a document at https://example.com/page.html sets a policy of 379 | None When Downgrade, then navigations to 380 | https://not.example.com/ would send a 381 | referer HTTP header with a value of 382 | https://example.com/page.html, as neither resource’s origin is an 383 | a priori insecure origin. 384 | 385 |

Navigations from that same page to 386 | http://not.example.com/ would send no 387 | referer header.

388 |
389 | 390 |

This is a user agent’s default behavior, if no policy is otherwise specified.

391 | 392 |

3.3 Origin Only

393 | 394 |

The Origin Only policy specifies that only the 395 | ASCII serialization of the 396 | origin of the global environment from which a request is 397 | made is sent as referrer information when making both same-origin 398 | requests and cross-origin requests from a particular 399 | global environment.

400 | 401 |

Note: The serialization of an origin looks like 402 | https://example.com. To ensure that a valid URL is sent in the 403 | `Referer` header, user agents will append a U+002F SOLIDUS 404 | ("/") character to the origin (e.g. 405 | https://example.com/).

406 | 407 |
408 | If a document at https://example.com/page.html sets a policy of 409 | Origin Only, then navigations to any origin would send a 410 | referer header with a value of 411 | https://example.com/, even to a priori insecure 412 | origins. 413 |
414 | 415 |

3.4 Origin When Cross-Origin

416 | 417 |

The Origin When Cross-Origin policy specifies that a full URL, 418 | stripped for use as a referrer, is sent as referrer 419 | information when making same-origin requests from a particular 420 | global environment, and only the 421 | ASCII serialization of the 422 | origin of the global environment from which a request is 423 | made is sent at referrer information when making cross-origin requests 424 | from a particular global environment.

425 | 426 |

Note: For the Origin When Cross-Origin policy, we also consider 427 | protocol upgrades, e.g. requests from http://exmaple.com/ to 428 | https://example.com/ to be cross-origin requests.

429 | 430 |
431 | If a document at https://example.com/page.html sets a policy of 432 | Origin When Cross-Origin, then navigations to any 433 | https://example.com/not-page.html would send a 434 | referer header with a value of 435 | https://example.com/page.html. 436 | 437 |

Navigations from that same page to https://not.example.com/ 438 | would send a referer header with a value of 439 | https://example.com/, even to a priori insecure 440 | origins.

441 |
442 | 443 |

3.5 Unsafe URL

444 | 445 |

The Unsafe URL policy specifies that a full URL, 446 | stripped for use as a referrer, is sent along with 447 | both cross-origin requests and same-origin requests made from 448 | a particular global environment.

449 | 450 |
451 | If a document at https://example.com/sekrit.html sets a policy 452 | of Unsafe URL, then navigations to 453 | http://not.example.com/ (and every other origin) would send a 454 | referer HTTP header with a value of 455 | https://example.com/sekrit.html. 456 |
457 | 458 |

Note: The policy’s name doesn’t lie; it is unsafe. This policy will leak 459 | origins and paths from TLS-protected resources to insecure origins. 460 | Carefully consider the impact of setting such a policy for potentially 461 | sensitive documents. 462 |

463 | 464 |
465 |

4 Referrer Policy Delivery

466 | 467 |

A JavaScript global environment’s referrer policy is delivered 468 | in one of four ways:

469 | 470 | 493 | 494 |

The CSP-based delivery mechanisms are defined in the Content Security Policy 495 | specification. [CSP] The meta and implicit mechanisms are 496 | defined below.

497 | 498 |

4.1 Delivery via meta

499 | 500 |

When an HTML meta element with a name attribute 501 | that is a case-insensitive match for the string "Referrer" is 502 | inserted into a document, for example:

503 | 504 | 
<meta name="referrer" content="origin">
 505 |
506 | 507 |

Add the following entry to the 508 | pragma directives 509 | for the meta element:

510 | 511 |
512 |
513 | Referrer policy 514 | (name="Referrer") 515 |
516 |
517 |
    518 |
  1. If the Document’s head element is 519 | not an ancestor of the meta element, abort 520 | these steps.
    2. 521 | 522 |
  2. 523 | If the meta element lacks a 524 | content attribute, or if that 525 | attribute’s value is the empty string, then abort these steps. 526 |
    3. 527 | 528 |
  3. 529 | Let environment be the global environment associated 530 | with the Document. 531 |
    4. 532 | 533 |
  4. 534 | Let meta-value be the value of the element’s 535 | content attribute, after 536 | stripping 537 | leading and trailing whitespace. 538 |
    5. 539 | 540 |
  5. 541 | Let policy be the value associated with the first of the 542 | following keywords which is a case-insensitive match for 543 | meta-value: 544 | 545 |
    546 |
    never
    547 |
    none
    548 |
    None
    549 | 550 |
    origin
    551 |
    Origin
    552 | 553 |
    default
    554 |
    none-when-downgrade
    555 |
    None When Downgrade
    556 | 557 |
    origin-when-crossorigin
    558 |
    Origin When Cross-Origin
    559 | 560 |
    always
    561 |
    unsafe-url
    562 |
    Unsafe URL
    563 |
    564 |
    6. 565 | 566 |
  6. 567 | Execute the §6.1 568 | Set environment’s referrer policy to policy. 569 | algorithm on 570 | environment using policy, if policy 571 | is not null. 572 |
    7. 573 |
574 | 575 |

Note: Authors are encouraged to avoid the legacy keywords 576 | never, default, and always. The 577 | keywords none, none-when-downgrade, and 578 | unsafe-url respectively are preferred.

579 | 580 |

What is the interaction with the preload scanner? 581 |

582 |
583 | 584 |

4.2 Implicit Delivery

585 | 586 |

A global environment inherits the referrer policy of another 587 | environment in several circumstances:

588 | 589 |

4.2.1 590 | Nested Browsing Contexts 591 |

592 | 593 |

Whenever a user agent creates a nested browsing context containing 594 | an iframe srcdoc document or a resource whose origin’s scheme 595 | is not a relative scheme (for instance, a blob or 596 | data resource):

597 | 598 |
    599 |
  1. 600 | Let environment be the nested browsing context’s 601 | JavaScript global environment. 602 |
    2. 603 |
  2. 604 | Let policy be the parent browsing context’s 605 | JavaScript global environment’s referrer policy. 606 |
    3. 607 |
  3. 608 | Execute the §6.1 609 | Set environment’s referrer policy to policy. 610 | algorithm on 611 | environment using policy, if policy 612 | is not null. 613 |
    4. 614 |
615 | 616 |

4.2.2 617 | Workers 618 |

619 | 620 |

Whenever a user agent runs a worker: 621 | scheme is not a relative scheme:

622 | 623 |

What about service workers?

624 | 625 |
    626 |
  1. 627 | Let environment be the Worker’s JavaScript global 628 | environment. 629 |
    2. 630 |
  2. 631 | Let policy be the None when downgrade 632 |
    3. 633 |
  3. 634 | Execute the §6.1 635 | Set environment’s referrer policy to policy. 636 | algorithm on 637 | environment using policy. 638 |
    4. 639 |
640 |
641 | 642 |
643 |

5 Integration with Fetch

644 | 645 |

The Fetch specification calls out to the 646 | Determine request’s 647 | referrer algorithm as 648 | Step 2 of the 649 | Fetching algorithm, and uses the response to set the request’s 650 | referrer property. Fetch is responsible for serializing the 651 | URL provided, and setting the `Referer` header on 652 | request. 653 |

654 | 655 |
656 |

6 Algorithms

657 | 658 |

6.1 659 | Set environment’s referrer policy to policy. 660 |

661 | 662 |

If no referrer policy has been set for a global environment, then 663 | setting its value is straightforward. If a policy has previously been set, 664 | however, then we need to deal with potential conflict. We handle conflict 665 | in a draconian fashion: conflicts resolve to None, as described 666 | below.

667 | 668 |
    669 |
  1. If policy is not one of None, 670 | None when downgrade, Origin Only, 671 | Origin when cross-origin, or 672 | Unsafe URL, then set policy to 673 | None.
    2. 674 | 675 |
  2. 676 | Let currentPolicy be the value of environment’s 677 | referrer policy. 678 |
    3. 679 | 680 |
  3. 681 | If currentPolicy is null (that is, if no policy has 682 | been explicitly set), then: 683 | 684 |
      685 |
    1. 686 | Set environment’s referrer policy to 687 | policy. 688 |
      2. 689 |
    2. 690 | Skip the remaining steps. 691 |
      3. 692 |
    693 |
    4. 694 | 695 |
  4. 696 | If currentPolicy is not policy, then set 697 | environment’s referrer policy to Never. 698 |
    5. 699 |
700 | 701 |

6.2 702 | Determine request’s Referrer. 703 |

704 | 705 |

Given a Request request, we can determine the correct 706 | referrer information to send by examining the policy associated with 707 | its client’s global environment, as detailed in the 708 | following steps, which returns either none or a URL:

709 | 710 |

Note: If Fetch is performing a navigation in response to a link of type 711 | noreferrer, then request’s 712 | referrer will be none, and Fetch won’t call into 713 | this algorithm.

714 | 715 |
    716 |
  1. 717 | Let environment be request’s client. 718 |
    2. 719 |
  2. 720 | Let policy be the value of environment’s 721 | referrer policy. 722 |
    3. 723 |
  3. 724 | If request’s referrer is a URL, then let 725 | referrerSource be request’s 726 | referrer. Otherwise: 727 | 728 |
      729 |
    1. 730 | If environment is a document environment: 731 | 732 |
        733 |
      1. 734 | Let document be the Document object of the 735 | active document of the browsing context of 736 | environment’s global object. 737 |
        2. 738 |
      739 |
      2. 740 |
    2. 741 | Otherwise, environment is a worker environment: 742 | 743 |
        744 |
      1. 745 | Let source be the API referrer source 746 | specified by the entry settings object. 747 |
        2. 748 |
      2. 749 | If source is a URL, let referrerSource 750 | be source, otherwise let document be 751 | source. 752 |
        3. 753 |
      754 |
      3. 755 |
    3. 756 | If document is set, execute the following steps: 757 | 758 |
        759 |
      1. 760 | If document’s origin is not a scheme/host/port 761 | tuple (because, for example, it has been sandboxed into a unique 762 | origin), return none and abort these steps. 763 |
        2. 764 |
      2. 765 | While document corresponds to an iframe srcdoc Document, 766 | let document be that Document’s browsing context’s 767 | browsing context container’s Document. 768 |
        3. 769 |
      3. 770 | Let referrerSource be document’s URL. 771 |
        4. 772 |
      773 |
      4. 774 |
    775 |
    4. 776 |
  4. 777 | Let referrerURL be the result of stripping 778 | referrerSource for use as a referrer. 779 |
    5. 780 |
  5. 781 | Let referrerOrigin be the result of 782 | stripping referrerSource for use as a 783 | referrer, with the origin-only flag set to 784 | true. 785 |
    6. 786 | 787 |
  6. 788 | Execute the statements corresponding to the value of policy: 789 | 790 |
    791 |
    policy is None
    792 |
    Return none
    793 | 794 |
    policy is Origin
    795 |
    Return referrerOrigin
    796 | 797 |
    policy is Unsafe URL
    798 |
    Return referrerURL.
    799 | 800 |
    801 | policy is Origin When Cross-Origin 802 |
    803 |
    804 |
      805 |
    1. 806 | If request is a cross-origin request, then 807 | return referrerOrigin. 808 |
      2. 809 |
    2. 810 | Otherwise, return referrerURL. 811 |
      3. 812 |
    813 |
    814 | 815 |
    816 | policy is None When Downgrade 817 |
    818 |
    819 | policy is null 820 |
    821 |
    822 |
      823 |
    1. 824 | If environment is TLS-protected and the 825 | origin of request’s URL is 826 | an a priori insecure origin, then return 827 | none. 828 |
      2. 829 |
    2. 830 | Otherwise, return requestURL. 831 |
      3. 832 |
    833 |
    834 |
    835 |
    7. 836 |
837 | 838 |

Note: Nothing here should be interpreted as preventing user agents from 839 | offering options to users which would reduce the information sent out via a 840 | `Referer` header. For instance, user agents MAY allow users to 841 | suppress the referrer header entirely, regardless of the referrer 842 | policy.

843 | 844 |

6.3 845 | Strip url for use as a referrer. 846 |

847 | 848 |

Certain portions of URLs MUST not be included when sending a URL as the value 849 | of a `Referer` header: a URLs fragment, username, and password 850 | components should be stripped from the URL before it’s sent out. This 851 | algorithm accepts a origin-only flag, which defaults 852 | to false. If set to true, the algorithm will 853 | additionally remove the URL’s path and query components, leaving only the 854 | scheme, host, and port.

855 | 856 |
    857 |
  1. 858 | If url is null, return none. 859 |
    2. 860 |
  2. 861 | If url’s scheme is not a relative 862 | scheme, then return none. 863 |
    3. 864 |
  3. 865 | Set url’s username to the empty string. 866 |
    4. 867 |
  4. 868 | Set url’s password to null. 869 |
    5. 870 |
  5. 871 | Set url’s fragment to null. 872 |
    6. 873 |
  6. 874 | If the origin-only flag is true, 875 | then: 876 | 877 |
      878 |
    1. 879 | Set url’s path to null. 880 |
      2. 881 |
    2. 882 | Set url’s query to null. 883 |
      3. 884 |
    885 |
    7. 886 |
  7. 887 | Return url. 888 |
    8. 889 |
890 |
891 | 892 | 893 |
894 |

7 Acknowledgements

895 | 896 |

This specification is based in large part on Adam Barth and Jochen Eisinger’s 897 | Meta referrer 898 | document. 899 |

900 | 901 |

Conformance

902 | 903 |

Document conventions

904 | 905 |

Conformance requirements are expressed with a combination of 906 | descriptive assertions and RFC 2119 terminology. The key words "MUST", 907 | "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 908 | "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this 909 | document are to be interpreted as described in RFC 2119. 910 | However, for readability, these words do not appear in all uppercase 911 | letters in this specification. 912 | 913 |

All of the text of this specification is normative except sections 914 | explicitly marked as non-normative, examples, and notes. [RFC2119]

915 | 916 |

Examples in this specification are introduced with the words "for example" 917 | or are set apart from the normative text with class="example", 918 | like this: 919 | 920 |

921 |

This is an example of an informative example.

922 |
923 | 924 |

Informative notes begin with the word "Note" and are set apart from the 925 | normative text with class="note", like this: 926 | 927 |

Note, this is an informative note.

928 | 929 |

Conformant Algorithms

930 | 931 |

Requirements phrased in the imperative as part of algorithms (such as 932 | "strip any leading space characters" or "return false and abort these 933 | steps") are to be interpreted with the meaning of the key word ("must", 934 | "should", "may", etc) used in introducing the algorithm.

935 | 936 |

Conformance requirements phrased as algorithms or specific steps can be 937 | implemented in any manner, so long as the end result is equivalent. In 938 | particular, the algorithms defined in this specification are intended to 939 | be easy to understand and are not intended to be performant. Implementers 940 | are encouraged to optimize.

941 | 942 |

Conformance Classes

943 | 944 |

A conformant user agent must implement all the requirements 945 | listed in this specification that are applicable to user agents.

946 | 947 |

A conformant server must implement all the requirements listed 948 | in this specification that are applicable to servers.

949 | 950 | 951 |

952 | References

953 | 954 |

955 | Normative References

956 |
957 |
[CSP]
Brandon Sterne; Adam Barth. Content Security Policy 1.0. 15 November 2012. W3C Candidate Recommendation. (Work in progress.) URL: http://www.w3.org/TR/2012/CR-CSP-20121115/
958 |
[ECMA-262]
???. ECMAScript Language Specification, Third Edition. December 1999. URL: http://www.ecma-international.org/publications/standards/Ecma-262.htm
959 |
[FETCH]
Anne van Kesteren. Fetch. Living Standard. URL: http://fetch.spec.whatwg.org/
960 |
[HTML5]
Robin Berjon; et al. HTML5. 17 June 2014. W3C Candidate Recommendation. (Work in progress.) URL: http://www.w3.org/TR/2014/WD-html5-20140617/
961 |
[MIX]
Mike West. Mixed Content. ED. URL: https://w3c.github.io/webappsec/specs/mixedcontent/
962 |
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. URL: http://www.ietf.org/rfc/rfc2119.txt
963 |
[RFC6454]
Adam Barth. The Web Origin Concept. RFC. URL: http://www.ietf.org/rfc/rfc6454.txt
964 |
[RFC7231]
Roy T. Fielding; Julian F. Reschke. HTTP/1.1 Semantics and Content. RFC. URL: http://www.ietf.org/rfc/rfc7231.txt
965 |
[URL]
Anne van Kesteren. URL. Living Standard. URL: http://url.spec.whatwg.org/
966 |
[WORKERS]
Ian Hickson. Web Workers. 1 May 2012. W3C Candidate Recommendation. (Work in progress.) URL: http://www.w3.org/TR/2012/CR-workers-20120501/
967 |
[WSC-UI]
Thomas Roessler; Anil Saldhana. Web Security Context: User Interface Guidelines. 12 August 2010. W3C Recommendation. URL: http://www.w3.org/TR/2010/REC-wsc-ui-20100812/
968 |
969 | 970 |

971 | Informative References

972 |
973 |
[CAPABILITY-URLS]
Jenni Tennison. Capability URLs. WD. URL: http://www.w3.org/TR/capability-urls/
974 |
975 | 976 |

977 | Index

978 |
    979 |
  • API referrer source, 2.2 980 |
  • a priori insecure origin, 2.2 981 |
  • ASCII serialization of an origin, 2.2 982 |
  • client, 2.2 983 |
  • conformant server, Unnumbered section 984 |
  • conformant user agent, Unnumbered section 985 |
  • context, 2.2 986 |
  • cross-origin, 2.2 987 |
  • cross-origin request, 2.2 988 |
  • document environment, 2.2 989 |
  • Entry settings object, 2.2 990 |
  • fetch, 2.2 991 |
  • global environment, 2.2 992 |
  • global object, 2.2 993 |
  • JavaScript global environment, 2.2 994 |
  • None, 3.1 995 |
  • None When Downgrade, 3.2 996 |
  • origin, 2.2 997 |
  • Origin Only, 3.3 998 |
  • origin-only flag, 6.3 999 |
  • Origin When Cross-Origin, 3.4 1000 |
  • policy, 2.1 1001 |
  • Referer, 2.2 1002 |
  • Referer header, 2.2 1003 |
  • Referer HTTP header field, 2.2 1004 |
  • referrer policy, 2.1 1005 |
  • relative scheme, 2.2 1006 |
  • request, 2.2 1007 |
  • request client, 2.2 1008 |
  • request context, 2.2 1009 |
  • runs a worker, 2.2 1010 |
  • same-origin, 2.2 1011 |
  • same-origin request, 2.2 1012 |
  • TLS-protected, 2.2 1013 |
  • Unsafe URL, 3.5 1014 |
  • worker environment, 2.2 1015 |
1016 | 1017 | 1018 | 1019 |

Issues Index

What is the interaction with the preload scanner? 1020 | ↵
What about service workers? ↵
1021 | 1022 |
1023 | -------------------------------------------------------------------------------- /published/2016-06-01-REFERRER-WD.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | Referrer Policy 6 | 7 | 65 | 66 | 67 | 68 | 69 |
70 |

W3C

71 |

Referrer Policy

72 |

W3C Working Draft,

73 |
74 |
75 |
This version: 76 |
http://www.w3.org/TR/2016/WD-referrer-policy-20160601/ 77 |
Latest version: 78 |
http://www.w3.org/TR/referrer-policy/ 79 |
Editor's Draft: 80 |
http://w3c.github.io/webappsec-referrer-policy/ 81 |
Previous Versions: 82 |
http://www.w3.org/TR/2014/WD-referrer-policy-20140807/ 83 |
Version History: 84 |
https://github.com/w3c/webappsec-referrer-policy/commits/gh-pages 85 |
Feedback: 86 |
public-webappsec@w3.org with subject line “[REFERRER] … message topic …” (archives) 87 |
Issue Tracking: 88 |
GitHub 89 |
Editors: 90 |
(Google Inc.) 91 |
(Google Inc.) 92 |
93 |
94 |
95 |

Copyright © 2016 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and document use rules apply.

96 |
97 |
98 |

Abstract

99 |
100 |

This document describes how an author can set a referrer policy for documents they create, and the impact of such a policy on the Referer HTTP header for outgoing requests and navigations.

101 |
102 |

Status of this document

103 |
104 |

This section describes the status of this document at the time of 105 | its publication. Other documents may supersede this document. A list of 106 | current W3C publications and the latest revision of this technical report 107 | can be found in the W3C technical reports 108 | index at http://www.w3.org/TR/.

109 |

This document was published by the Web Application Security Working Group as a Working Draft. This document is intended to become a W3C Recommendation.

110 |

The (archived) public mailing list public-webappsec@w3.org (see instructions) 111 | is preferred for discussion of this specification. 112 | When sending e-mail, 113 | please put the text “REFERRER” in the subject, 114 | preferably like this: 115 | “[REFERRER] …summary of comment…”

116 |

Publication as a Working Draft does not imply endorsement by the W3C 117 | Membership. This is a draft document and may be updated, replaced or 118 | obsoleted by other documents at any time. It is inappropriate to cite this 119 | document as other than work in progress.

120 |

This document was produced by the Web Application Security Working Group.

121 |

This document was produced by a group operating under 122 | the 5 February 2004 W3C Patent Policy. 123 | W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; 124 | that page also includes instructions for disclosing a patent. 125 | An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

126 |

This document is governed by the 1 September 2015 W3C Process Document.

127 |

128 |
129 |
130 | 216 |
217 |
218 |

1. Introduction

219 |

This section is not normative.

220 |

Requests made from a document, and for navigations away from that document 221 | are associated with a Referer header. While the header 222 | can be suppressed for links with the noreferrer link 223 | type, authors might wish to control the Referer header 224 | more directly for a number of reasons:

225 |

1.1. Privacy

226 |

A social networking site has a profile page for each of its users, and users 227 | add hyperlinks from their profile page to their favorite bands. The social 228 | networking site might not wish to leak the user’s profile URL to the band web 229 | sites when other users follow those hyperlinks (because the profile URLs might 230 | reveal the identity of the owner of the profile).

231 |

Some social networking sites, however, might wish to inform the band web sites 232 | that the links originated from the social networking site but not reveal which 233 | specific user’s profile contained the links.

234 |

1.2. Security

235 |

A web application uses HTTPS and a URL-based session identifier. The web 236 | application might wish to link to HTTPS resources on other web sites without 237 | leaking the user’s session identifier in the URL.

238 |

Alternatively, a web application may use URLs which themselves grant some 239 | capability. Controlling the referrer can help prevent these capability URLs 240 | from leaking via referrer headers. [CAPABILITY-URLS]

241 |

Note that there are other ways for capability URLs to leak, and controlling 242 | the referrer is not enough to control all those potential leaks.

243 |

1.3. Trackback

244 |

A blog hosted over HTTPS might wish to link to a blog hosted over HTTP and 245 | receive trackback links.

246 |
247 |
248 |

2. Key Concepts and Terminology

249 |
250 |
referrer policy 251 |
252 | A referrer policy modifies the algorithm used to populate the Referer header when fetching subresources, 253 | prefetching, or performing navigations. This document defines the various 254 | behaviors for each referrer policy. 255 |

Every environment settings object has an algorithm for obtaining a referrer policy, which is used by default for all requests with that environment settings object as their request 256 | client.

257 |
same-origin request 258 |
A Request request is a same-origin request if request’s origin and the origin of request’s url are the same. 259 |
cross-origin request 260 |
A Request is a cross-origin request if it is not same-origin. 261 |
262 |
263 |
264 |

3. Referrer Policies

265 |

Each possible referrer policy, besides the empty string, is explained 266 | below. A detailed algorithm for evaluating their effect is given in the §5 Integration with Fetch and §7 Algorithms sections.

267 |

Note: The referrer policy for an environment settings object provides a 268 | default baseline policy for requests when that environment settings 269 | object is used as a request client. This policy may be tightened 270 | for specific requests via mechanisms like the noreferrer link type.

271 |

3.1. "no-referrer"

272 |

The simplest policy is "no-referrer", which specifies 273 | that no referrer information is to be sent along with requests made from a 274 | particular request client to any origin. The header will be 275 | omitted entirely.

276 |
If a document at https://example.com/page.html sets a policy of "no-referrer", then navigations to https://example.com/ (or any other URL) would send no Referer header.
277 |

3.2. "no-referrer-when-downgrade"

278 |

The "no-referrer-when-downgrade" policy sends a full URL 279 | along with requests from TLS-protected environment settings 280 | object to a a priori authenticated URL, and requests from request clients which are not TLS-protected to any origin.

281 |

Requests from TLS-protected request clients to non-a 282 | priori authenticated URLs, on the other hand, will contain no 283 | referrer information. A Referer HTTP header will not be 284 | sent.

285 |
286 | If a document at https://example.com/page.html sets a policy of "no-referrer-when-downgrade", then navigations to https://not.example.com/ would send a Referer HTTP header with a value of https://example.com/page.html, as neither resource’s origin is an 287 | non-a priori authenticated URL. 288 |

Navigations from that same page to http://not.example.com/ would send no Referer header.

289 |
290 |

This is a user agent’s default behavior, if no policy is otherwise specified.

291 |

3.3. "same-origin"

292 |

The "same-origin" policy specifies that a 293 | full URL, stripped for use as a referrer, is sent as 294 | referrer information when making same-origin requests from a particular request client.

295 |

Cross-origin requests, on the other hand, will contain no 296 | referrer information. A Referer HTTP header will not be 297 | sent.

298 |
299 | If a document at https://example.com/page.html sets a policy of "same-origin", then navigations to https://example.com/not-page.html would send a Referer header with a value of https://example.com/page.html. 300 |

Navigations from that same page to https://not.example.com/ would send no Referer header.

301 |
302 |

3.4. "origin"

303 |

The "origin" policy specifies that only the ASCII serialization of the origin of the request client is sent as referrer information 304 | when making both same-origin requests and cross-origin requests from a particular request client.

305 |

Note: The serialization of an origin looks like https://example.com. To ensure that a valid URL is sent in the 306 | `Referer` header, user agents will append a U+002F SOLIDUS 307 | ("/") character to the origin (e.g. https://example.com/).

308 |

Note: The "origin" policy causes the origin of HTTPS 309 | referrers to be sent over the network as part of unencrypted HTTP requests.

310 |
If a document at https://example.com/page.html sets a policy of "origin", then navigations to any origin would send a Referer header with a value 311 | of https://example.com/, even to URLs that are not a 312 | priori authenticated URLs.
313 |

3.5. "origin-when-cross-origin"

314 |

The "origin-when-cross-origin" policy specifies that a 315 | full URL, stripped for use as a referrer, is sent as 316 | referrer information when making same-origin requests from a particular request client, and only the ASCII serialization of the origin of the request client is sent as referrer information 317 | when making cross-origin requests from a particular request 318 | client.

319 |

Note: For the "origin-when-cross-origin" policy, we also 320 | consider protocol upgrades, e.g. requests from http://example.com/ to https://example.com/, to be cross-origin requests.

321 |

Note: The "origin-when-cross-origin" policy causes the 322 | origin of HTTPS referrers to be sent over the network as part of unencrypted 323 | HTTP requests.

324 |
325 | If a document at https://example.com/page.html sets a policy of "origin-when-cross-origin", then navigations to https://example.com/not-page.html would send a Referer header with a value of https://example.com/page.html. 326 |

Navigations from that same page to https://not.example.com/ would send a Referer header with a value of https://example.com/, even to URLs that are not a 327 | priori authenticated URLs.

328 |
329 |

3.6. "unsafe-url"

330 |

The "unsafe-url" policy specifies that a full URL, stripped for use as a referrer, is sent along with 331 | both cross-origin requests and same-origin requests made from 332 | a particular request client.

333 |
If a document at https://example.com/sekrit.html sets a policy 334 | of "unsafe-url", then navigations to http://not.example.com/ (and every other origin) would send a Referer HTTP header with a value of https://example.com/sekrit.html.
335 |

Note: The policy’s name doesn’t lie; it is unsafe. This policy will leak 336 | origins and paths from TLS-protected resources to insecure origins. 337 | Carefully consider the impact of setting such a policy for potentially 338 | sensitive documents.

339 |

3.7. The empty string

340 |

The empty string "" corresponds to no referrer policy, causing a 341 | fallback to a referrer policy defined elsewhere, or in the case where 342 | no such higher-level policy is available, defaulting to "no-referrer-when-downgrade". This defaulting happens in 343 | the §7.3 Determine request’s Referrer algorithm.

344 |
Given a HTML a element without any declared referrerpolicy attribute, its referrer policy is "". Thus, navigation requests initiated 345 | by clicking on that a element will be sent with the referrer policy of the a element’s node 346 | document. If that Document has "" as its referrer policy, the §7.3 Determine request’s Referrer algorithm will treat "" the same as "no-referrer-when-downgrade".
347 |
348 |
349 |

4. Referrer Policy Delivery

350 |

A request’s referrer policy is delivered in one of five ways:

351 | 359 |

4.1. Delivery via Referrer-Policy header

360 |

The Referrer-Policy HTTP 361 | header specifies the referrer policy that the user agent applies when 362 | determining what referrer information should be included with requests 363 | made, and with browsing contexts created from the context of the protected resource. 364 | The syntax for the name and value of the header are described by the 365 | following ABNF grammar:

366 | 
"Referrer-Policy:" 1#policy-token
367 |
368 | 
policy-token   = "no-referrer" / "no-referrer-when-downgrade" / "same-origin" / "origin" / "origin-when-cross-origin" / "unsafe-url"
369 |
370 |

Note: The header name does not share the HTTP Referer header’s misspelling.

371 |

§5 Integration with Fetch and §6 Integration with HTML describe 372 | how the Referrer-Policy header is processed.

373 |
374 |

4.1.1. Usage

375 |

This section is not normative.

376 |

A protected resource can prevent referrer leakage by specifying no-referrer as the value of its Referrer-Policy header:

377 | 
Referrer-Policy: no-referrer
378 |
379 |

This will cause all requests made from the protected resource’s 380 | context to have an empty Referer [sic] header.

381 |
382 |
383 |

4.2. Delivery via meta

384 |

This section is not normative.

385 |

The HTML Standard defines the referrer keyword for the meta element, which allows setting the referrer 386 | policy via markup.

387 |
388 |
389 |

4.3. Delivery 390 | via a referrerpolicy content attribute

391 |

This section is not normative.

392 |

The HTML Standard defines the concept of referrer policy 393 | attributes which applies to several of its elements, for example:

394 | 
<a href="http://example.com" referrerpolicy="origin">
395 |
396 |
397 |

4.4. Nested browsing contexts

398 |

This section is not normative.

399 |

The HTML Standard and Fetch Standard define how nested browsing contexts 400 | that are not created from responses, such as iframe elements with 401 | their srcdoc attribute set, or created from a blob URL, inherit 402 | their referrer policy from the creator browsing context or blob URL.

403 |
404 |
405 |
406 |

5. Integration with Fetch

407 |

This section is not normative.

408 |

The Fetch specification calls out to §7.2 Set request’s referrer policy on redirect immediately 409 | before Step 410 | 15 of the HTTP-redirect fetch.

411 |

The Fetch specification calls out to the Determine request’s 412 | referrer algorithm as Step 2 of the 413 | Fetching algorithm, and uses the result to set the request’s referrer property. Fetch is responsible for serializing the 414 | URL provided, and setting the `Referer` header on request.

415 |
416 |
417 |

6. Integration with HTML

418 |

This section is not normative.

419 |

The HTML Standard determines the referrer policy of any response 420 | received during navigation or while running a worker, and uses 421 | the result to set the resulting Document or WorkerGlobalScope's 422 | referrer policy. This is later used by the corresponding environment 423 | settings object, which serves as a request client for fetches it initiates.

424 |

TODO: define content attribute integrations. For example, for 425 | img elements, HTML should set the request’s associated referrer policy 426 | before fetching.

427 |

Note: W3C HTML5 does not define the referrerpolicy content 428 | attributes, or referrerPolicy IDL attributes, or the referrer keyword for meta, or the 429 | integration with navigation or running a worker. For this spec to make sense 430 | with W3C HTML5, those would need to be copied from [HTML].

431 |
432 |
433 |

7. Algorithms

434 |

7.1. Parse a referrer policy from a Referrer-Policy header

435 |

Given a Response response, the following steps return a referrer policy according to response’s `Referrer-Policy` header:

436 |
    437 |
  1. Let policy-tokens be the result of 438 | parsing `Referrer-Policy` in response’s header list. 439 |
  2. Let policy be the empty string. 440 |
  3. For each token in policy-tokens, execute §7.5 Determine token’s Policy on token and 441 | set policy to the result if it is not the empty string. 442 |
  4. Return policy. 443 |
444 |

7.2. Set request’s referrer policy on redirect

445 |

Given a request request and a response actualResponse, 446 | this algorithm updates request’s associated referrer policy according to the Referrer-Policy header (if any) in actualResponse.

447 |
    448 |
  1. Let policy be the result of executing §7.1 Parse a referrer policy from a Referrer-Policy header on actualResponse. 449 |
  2. If policy is not the empty string, then set request’s 450 | associated referrer policy to policy. 451 |
452 |

7.3. Determine request’s Referrer

453 |

Given a Request request, we can determine the correct 454 | referrer information to send by examining the referrer policy associated with it, as detailed in the following steps, which return 455 | either no referrer or a URL:

456 |

Note: If Fetch is performing a navigation in response to a link of type noreferrer, then request’s referrer will be no referrer, and Fetch won’t call 457 | into this algorithm.

458 |
    459 |
  1. Let policy be request’s associated referrer policy. 460 |
  2. Let environment be request’s client. 461 |
  3. 462 | If request’s referrer is a URL, then let referrerSource be request’s referrer. Otherwise: 463 |
      464 |
    1. 465 | If environment’s global object is a Window object: 466 |
        467 |
      1. Let document be the Document object of the active document of the browsing context of environment’s responsible browsing context. 468 |
      469 |
    2. 470 | Otherwise, environment’s global object is a WorkerGlobalScope: 471 |
        472 |
      1. Let source be the API referrer source specified by the incumbent settings object. 473 |
      2. If source is a URL, let referrerSource be source, otherwise let document be source. 474 |
      475 |
    3. 476 | If document is set, execute the following steps: 477 |
        478 |
      1. If document’s origin is an opaque 479 | origin (because, for example, it has been sandboxed 480 | into a unique origin), return no referrer and 481 | abort these steps. 482 |
      2. While document corresponds to an iframe srcdoc Document, 483 | let document be that Document’s browsing context’s browsing context container’s Document. 484 |
      3. Let referrerSource be document’s URL. 485 |
      486 |
    487 |
  4. Let referrerURL be the result of stripping referrerSource for use as a referrer. 488 |
  5. Let referrerOrigin be the result of stripping referrerSource for use as a 489 | referrer, with the origin-only flag set to true. 490 |
  6. 491 | Execute the statements corresponding to the value of policy: 492 |
    493 |
    "no-referrer" 494 |
    Return no referrer 495 |
    "origin" 496 |
    Return referrerOrigin 497 |
    "unsafe-url" 498 |
    Return referrerURL. 499 |
    "same-origin" 500 |
    501 |
      502 |
    1. If request is a same-origin request, then 503 | return referrerURL. 504 |
    2. Otherwise, return no referrer. 505 |
    506 |
    "origin-when-cross-origin" 507 |
    508 |
      509 |
    1. If request is a cross-origin request, then 510 | return referrerOrigin. 511 |
    2. Otherwise, return referrerURL. 512 |
    513 |
    "no-referrer-when-downgrade" 514 |
    the empty string 515 |
    516 |
      517 |
    1. 518 | If environment is not null: 519 |
        520 |
      1. If environment is TLS-protected and the origin of request’s current 521 | URL is not an a priori authenticated 522 | URL, then return no referrer. 523 |
      524 |
    2. Return referrerURL. 525 |
    526 |
    527 |
528 |

7.4. Strip url for use as a referrer

529 |

Certain portions of URLs MUST not be included when sending a URL as the value 530 | of a `Referer` header: a URLs fragment, username, and password 531 | components should be stripped from the URL before it’s sent out. This 532 | algorithm accepts a origin-only flag, which defaults 533 | to false. If set to true, the algorithm will 534 | additionally remove the URL’s path and query components, leaving only the 535 | scheme, host, and port.

536 |
    537 |
  1. If url is null, return no referrer. 538 |
  2. If url’s scheme is a local scheme, then 539 | return no referrer. 540 |
  3. Set url’s username to the empty string. 541 |
  4. Set url’s password to null. 542 |
  5. Set url’s fragment to null. 543 |
  6. 544 | If the origin-only flag is true, 545 | then: 546 |
      547 |
    1. Set url’s path to null. 548 |
    2. Set url’s query to null. 549 |
    550 |
  7. Return url. 551 |
552 |

7.5. Determine token’s Policy

553 |

Given a string token (for example, the value of a Referrer-Policy header), this algorithm will return the referrer policy it refers to:

554 |
    555 |
  1. If token is an ASCII case-insensitive match for the 556 | strings "never" or "no-referrer", return "no-referrer". 557 |
  2. If token is ASCII case-insensitive match for the string 558 | "default" or "no-referrer-when-downgrade", 559 | return "no-referrer-when-downgrade". 560 |
  3. If token is an ASCII case-insensitive match for the 561 | string "origin", return "origin". 562 |
  4. If token is an ASCII case-insensitive match for the 563 | string "same-origin", return "same-origin". 564 |
  5. If token is ASCII case-insensitive match for the string 565 | "origin-when-cross-origin", return "origin-when-cross-origin". 566 |
  6. If token is ASCII case-insensitive match for the strings 567 | "always" or "unsafe-url", 568 | return "unsafe-url". 569 |
  7. If token is empty, return "no-referrer". 570 |
  8. Return the empty string. 571 |
572 |

Note: Authors are encouraged to avoid the legacy keywords never, default, and always. The 573 | keywords no-referrer, no-referrer-when-downgrade, and unsafe-url respectively are preferred.

574 |
575 |
576 |

8. Privacy Considerations

577 |

8.1. User Controls

578 |

Nothing in this specification should be interpreted as preventing user 579 | agents from offering options to users which would change the information 580 | sent out via a `Referer` header. For instance, user agents 581 | MAY allow users to suppress the referrer header entirely, regardless of the 582 | active referrer policy on a page.

583 |
584 |
585 |

9. Security Considerations

586 |

9.1. Information Leakage

587 |

The referrer policies "origin" and "unsafe-url" might leak the origin and the URL of 588 | a secure site respectively via insecure transport.

589 |

Those two policies are include in the spec nevertheless to lower the friction 590 | of sites adopting secure transport.

591 |

9.2. Downgrade to less strict policies

592 |

The spec does not forbid downgrading to less strict policies, e.g., from "no-referrer" to "unsafe-url".

593 |

On the one hand, it is not clear which policy is more strict for all possible 594 | pairs of policies: While "no-referrer-when-downgrade" will 595 | not leak any information over insecure transport, and "origin" will, the latter reveals less information 596 | across cross-origin navigations.

597 |

On the other hand, allowing for setting less strict policies enables authors 598 | to define safe fallbacks as described in §10.1 Unknown Policy Values.

599 |
600 |
601 |

10. Authoring Considerations

602 |

10.1. Unknown Policy Values

603 |

As described in §7.5 Determine token’s Policy, unknown policy values 604 | will be ignored, and when multiple sources specify a referrer policy, 605 | the value of the latest one will be used. This makes it possible to 606 | deploy new policy values.

607 |
Suppose older user agents don’t understand 608 | the "unsafe-url" policy. A site can specify 609 | an "origin" policy followed by an "unsafe-url" policy: older user agents will ignore the 610 | unknown "unsafe-url" value and use "origin", while newer user agents will use "unsafe-url" because it is the last to be processed.
611 |
612 |
613 |

11. Acknowledgements

614 |

This specification is based in large part on Adam Barth and Jochen Eisinger’s Meta referrer document.

615 |
616 |
617 |

Conformance

618 |

Document conventions

619 |

Conformance requirements are expressed with a combination of 620 | descriptive assertions and RFC 2119 terminology. The key words "MUST", 621 | "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 622 | "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this 623 | document are to be interpreted as described in RFC 2119. 624 | However, for readability, these words do not appear in all uppercase 625 | letters in this specification.

626 |

All of the text of this specification is normative except sections 627 | explicitly marked as non-normative, examples, and notes. [RFC2119]

628 |

Examples in this specification are introduced with the words "for example" 629 | or are set apart from the normative text with class="example", 630 | like this:

631 |
632 | 633 |

This is an example of an informative example.

634 |
635 |

Informative notes begin with the word "Note" and are set apart from the 636 | normative text with class="note", like this:

637 |

Note, this is an informative note.

638 |

Conformant Algorithms

639 |

Requirements phrased in the imperative as part of algorithms (such as 640 | "strip any leading space characters" or "return false and abort these 641 | steps") are to be interpreted with the meaning of the key word ("must", 642 | "should", "may", etc) used in introducing the algorithm.

643 |

Conformance requirements phrased as algorithms or specific steps can be 644 | implemented in any manner, so long as the end result is equivalent. In 645 | particular, the algorithms defined in this specification are intended to 646 | be easy to understand and are not intended to be performant. Implementers 647 | are encouraged to optimize.

648 |

Index

649 |

Terms defined by this specification

650 | 665 |

Terms defined by reference

666 | 760 |

References

761 |

Normative References

762 |
763 |
[FETCH] 764 |
Anne van Kesteren. Fetch. Living Standard. URL: http://fetch.spec.whatwg.org/ 765 |
[HTML] 766 |
Ian Hickson. HTML Standard. Living Standard. URL: https://html.spec.whatwg.org/multipage/ 767 |
[MIX] 768 |
Mike West. Mixed Content. ED. URL: https://w3c.github.io/webappsec-mixed-content/ 769 |
[RFC6454] 770 |
Adam Barth. The Web Origin Concept. RFC. URL: http://www.ietf.org/rfc/rfc6454.txt 771 |
[RFC7231] 772 |
Roy T. Fielding; Julian F. Reschke. HTTP/1.1 Semantics and Content. RFC. URL: http://www.ietf.org/rfc/rfc7231.txt 773 |
[DOM-LS] 774 |
Document Object Model URL: https://dom.spec.whatwg.org/ 775 |
[RFC2119] 776 |
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119 777 |
[URL] 778 |
Anne van Kesteren; Sam Ruby. URL. 9 December 2014. WD. URL: http://www.w3.org/TR/url-1/ 779 |
[WSC-UI] 780 |
Thomas Roessler; Anil Saldhana. Web Security Context: User Interface Guidelines. 12 August 2010. REC. URL: http://www.w3.org/TR/wsc-ui/ 781 |
782 |

Informative References

783 |
784 |
[CAPABILITY-URLS] 785 |
Jenni Tennison. Capability URLs. WD. URL: http://www.w3.org/TR/capability-urls/ 786 |
787 |

Issues Index

788 |
789 |
TODO: define content attribute integrations. For example, for 790 | img elements, HTML should set the request’s associated referrer policy 791 | before fetching. ↵
792 |
793 | 794 | 795 | 796 | --------------------------------------------------------------------------------