„Same-site“ und „same-origin“ werden häufig zitiert, aber oft missverstanden. Sie werden beispielsweise im Zusammenhang mit Seitenübergängen, fetch()
-Anfragen, Cookies, Pop-ups, eingebetteten Ressourcen und iFrames verwendet. Auf dieser Seite wird erläutert, was sie sind und wie sie sich voneinander unterscheiden.
Ursprung
![Ursprung](https://web.dev/static/articles/same-site-same-origin/image/origin-scheme.png?authuser=6&hl=de)
Der „Ursprung“ ist eine Kombination aus einem Schema (auch als Protokoll wie HTTP oder HTTPS bezeichnet), einem Hostnamen und einem Port (falls angegeben). Bei der URL https://www.example.com:443/foo
ist der „origin“ z. B. https://www.example.com:443
.
„Same-origin“ und „cross-origin“
Websites mit derselben Kombination aus Schema, Hostnamen und Port gelten als „Same-Origin“. Alles andere wird als ursprungsübergreifend betrachtet.
Abflugort A | Abflugort B | „Same-origin“ oder „cross-origin“? |
---|---|---|
https://www.example.com:443 | https://www.evil.com:443 | Ursprungsübergreifend: verschiedene Domains |
https://example.com:443 | Ursprungsübergreifend: verschiedene Subdomains | |
https://login.beispiel.de:443 | Ursprungsübergreifend: verschiedene Subdomains | |
http://www.beispiel.de:443 | Ursprungsübergreifend: verschiedene Schemas | |
https://www.beispiel.de:80 | Ursprungsübergreifend: verschiedene Ports | |
https://www.beispiel.de:443 | Gleicher Ursprung: genau passend | |
https://www.example.com | Same-Origin: Implizite Portnummer (443) stimmt überein |
Website
![Website (TLD+1)](https://web.dev/static/articles/same-site-same-origin/image/site-tld1-ae5ebbc587fbe.png?authuser=6&hl=de)
Top-Level-Domains (TLDs) wie .com
und .org
werden in der Stammzonendatenbank aufgeführt. Im vorherigen
Beispiel ist "site" eine Kombination aus dem Schema, der TLD und dem Teil der Domain unmittelbar davor (er heißt TLD+1). Beispiel: Wenn die URL https://www.example.com:443/foo
lautet, ist die „Website“ https://example.com
.
Liste der öffentlichen Suffixe und eTLD
Bei Domains mit Elementen wie .co.jp
oder .github.io
reicht es nicht aus, nur .jp
oder .io
zu verwenden, um die „Website“ zu identifizieren. Es gibt keine Möglichkeit, die Ebene registrierfähiger Domains für eine bestimmte TLD mithilfe eines Algorithmus zu bestimmen.
Dazu definiert die Public Suffix List eine Liste öffentlicher Suffixe, die auch als effektive TLDs (eTLDs) bezeichnet werden. Die Liste der eTLDs finden Sie unter publicsuffix.org/list.
Um den „Website“-Teil einer Domain mit einer eTLD zu ermitteln, gehen Sie genauso vor wie im Beispiel mit .com
. Nehmen wir https://www.project.github.io:443/foo
als Beispiel: Das Schema ist https
, die eTLD ist .github.io
und die eTLD+1 ist project.github.io
. https://project.github.io
wird also als „Website“ für diese URL betrachtet.
![Website (eTLD+1)](https://web.dev/static/articles/same-site-same-origin/image/site-etld1-2ffebe0e355bd.png?authuser=6&hl=de)
„same-site“ und „cross-site“
Websites mit demselben Schema und derselben eTLD+1 gelten als „same-site“. Websites mit einem anderen Schema oder einer anderen eTLD+1 sind „websiteübergreifend“.
Abflugort A | Abflugort B | „Websiteübergreifend“ oder „websiteübergreifend“? |
---|---|---|
https://www.example.com:443 | https://www.evil.com:443 | Websiteübergreifend: verschiedene Domains |
https://login.beispiel.de:443 | Gleiche Website: Unterschiedliche Subdomains spielen keine Rolle | |
http://www.beispiel.de:443 | Websiteübergreifend: unterschiedliche Schemas | |
https://www.beispiel.de:80 | Same-Site: Verschiedene Ports spielen keine Rolle | |
https://www.beispiel.de:443 | Gleiche Website: genau passend | |
https://www.example.com | Same-Site: Ports spielen keine Rolle |
„Schemalose Same-Site“
![schemalose Same-Site-Website](https://web.dev/static/articles/same-site-same-origin/image/schemeless-same-site-3ba215c9666cd.png?authuser=6&hl=de)
Die Definition von „same-site“ wurde geändert und das URL-Schema als Teil der Website aufgenommen, um zu verhindern, dass HTTP als schwacher Kanal verwendet wird.
Das ältere Konzept von „same-site“ ohne Schemavergleich heißt jetzt „schemaless same-site“. Beispielsweise werden http://www.example.com
und https://www.example.com
als schemalose Same-Site-, aber nicht als Same-Site-Website betrachtet, da nur der eTLD+1-Teil relevant ist und das Schema nicht berücksichtigt wird.
Abflugort A | Abflugort B | „Schemalose SameSite“ oder „Cross-Site“? |
---|---|---|
https://www.example.com:443 | https://www.evil.com:443 | Websiteübergreifend: verschiedene Domains |
https://login.beispiel.de:443 | Schemalose Same-Site: Unterschiedliche Subdomains spielen keine Rolle | |
http://www.beispiel.de:443 | Schemalose Same-Site: verschiedene Schemata sind nicht relevant | |
https://www.beispiel.de:80 | Schemalose Same-Site: verschiedene Ports spielen keine Rolle | |
https://www.beispiel.de:443 | Schemalose identische Website: genau passend | |
https://www.example.com | Schemalose Same-Site: Ports spielen keine Rolle |
Prüfen, ob eine Anfrage „same-site“, „same-origin“ oder „cross-site“ ist
Alle modernen Browser senden Anfragen mit einem Sec-Fetch-Site
-HTTP-Header.
Der Header hat einen der folgenden Werte:
cross-site
same-site
(bezieht sich auf eine schematische Website)same-origin
none
Sie können den Wert von Sec-Fetch-Site
prüfen, um festzustellen, ob die Anfrage Same-Site, Same-Origin oder websiteübergreifend ist.
Sie können dem Wert des Sec-Fetch-Site
-Headers ausreichend vertrauen, weil
- HTTP-Header, die mit
Sec-
beginnen, können nicht von JavaScript geändert werden - Diese Überschriften werden immer vom Browser festgelegt.