「same-site」と「same-origin」は頻繁に引用されますが、用語は誤解されがちです。たとえば、ページ遷移、fetch()
リクエスト、Cookie、ポップアップを開く、埋め込みリソース、iframe のコンテキストで言及されています。
原点
「送信元」は、スキーム(HTTP や HTTPS などのプロトコルとも呼ばれます)、ホスト名、ポート(指定されている場合)を組み合わせたものです。たとえば、URL が https://www.example.com:443/foo
の場合、「origin」は https://www.example.com:443
です。
「same-origin」と「cross-origin」
同じスキーム、ホスト名、ポートの組み合わせを持つウェブサイトは「同一オリジン」とみなされます。それ以外はすべて「クロスオリジン」とみなされます。
オリジン A | オリジン B | オリジン A とオリジン B が「same-origin」と「cross-origin」のどちらであるかの説明 |
---|---|---|
https://www.example.com:443 | https://www.evil.comwww.evil.com:443 | クロスオリジン: 異なるドメイン |
https://example.comexample.com:443 | クロスオリジン: 異なるサブドメイン | |
https://[ログイン].example.com:443 | クロスオリジン: 異なるサブドメイン | |
http://www.example.com:443 | クロスオリジン: さまざまなスキーム | |
https://www.example.com:80 | クロスオリジン: 異なるポート | |
https://www.example.com:443 | same-origin: 完全一致 | |
https://www.example.com | same-origin: 暗黙的なポート番号(443)の一致 |
サイト
.com
や .org
などのトップレベル ドメイン(TLD)は、ルートゾーン データベースにリストされています。上記の例の「サイト」は、スキーム、TLD、およびその直前のドメインの部分(ここでは TLD+1 と呼びます)を組み合わせたものです。たとえば、URL が https://www.example.com:443/foo
の場合、「サイト」は https://example.com
です。
パブリック サフィックス リストと eTLD
.co.jp
や .github.io
などを含むドメインの場合、.jp
や .io
を使用するだけでは「サイト」を特定できるほど詳細ではありません。特定の TLD の登録可能なドメインのレベルをアルゴリズム的に判断する方法はありません。そのため、公開サフィックス リストで定義された公開サフィックスのリストが作成されました。このような公開サフィックスは、有効な TLD(eTLD)とも呼ばれます。eTLD のリストは publicsuffix.org/list で管理されています。
eTLD を含むドメインの「サイト」部分を識別するには、.com
の例と同じ方法を適用します。たとえば、https://www.project.github.io:443/foo
では、スキームが https
、eTLD が .github.io
、eTLD+1 が project.github.io
であるため、https://project.github.io
はこの URL の「サイト」と見なされます。
「same-site」と「cross-site」
同じスキームと同じ eTLD+1 のウェブサイトは、「同一サイト」と見なされます。スキームや eTLD+1 が異なるウェブサイトは「クロスサイト」です。
オリジン A | オリジン B | オリジン A とオリジン B が「同一サイト」か「クロスサイト」かの説明 |
---|---|---|
https://www.example.com:443 | https://www.evil.comwww.evil.com:443 | クロスサイト: 異なるドメイン |
https://[ログイン].example.com:443 | same-site: 異なるサブドメインは問わない | |
http://www.example.com:443 | クロスサイト: さまざまなスキーム | |
https://www.example.com:80 | same-site: 異なるポートは重要ではない | |
https://www.example.com:443 | same-site: 完全一致 | |
https://www.example.com | same-site: ポートは重要ではない |
「スキームのない同一サイト」
HTTP が脆弱なチャネルとして使用されることを防ぐため、「同一サイト」の定義は、URL スキームをサイトの一部とみなすよう進化しました。スキーム比較のない以前の「同一サイト」のコンセプトは、「スキームレス同一サイト」と呼ばれるようになりました。たとえば、http://www.example.com
と https://www.example.com
は、eTLD+1 の部分のみが重要であり、スキームは考慮されないため、スキームのない同一サイトと見なされます。
オリジン A | オリジン B | 送信元 A と B が「スキームのない同一サイト」かどうかの説明 |
---|---|---|
https://www.example.com:443 | https://www.evil.comwww.evil.com:443 | クロスサイト: 異なるドメイン |
https://[ログイン].example.com:443 | スキームのない同一サイト: 異なるサブドメインは問わない | |
http://www.example.com:443 | スキームがない同一サイト: スキームは問わない | |
https://www.example.com:80 | スキームのない同一サイト: 異なるポートは問わない | |
https://www.example.com:443 | スキームのない同一サイト: 完全一致 | |
https://www.example.com | スキームのない同一サイト: ポートは重要ではない |
リクエストが「same-site」、「same-origin」、「cross-site」のいずれであるかを確認する方法
最新のブラウザ(Safari では近日提供予定)はすべて、Sec-Fetch-Site
HTTP ヘッダーとともにリクエストを送信します。ヘッダーには次のいずれかの値があります。
cross-site
same-site
same-origin
none
Sec-Fetch-Site
の値を調べることで、リクエストが「same-site」、「same-origin」、「cross-site」のいずれであるかを判別できます。