「same-site」と「same-origin」を理解する

Eiji Kitamura

「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）の一致

サイト

サイト（TLD+1）

.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 の「サイト」と見なされます。

サイト（eTLD+1）

「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」のいずれであるかを判別できます。