「Same-site」と「same-origin」

「同一サイト」と「同一オリジン」はしばしば引用されますが、用語は誤解されがちです。たとえば、ページの遷移、fetch() リクエスト、Cookie、ポップアップの表示、埋め込みリソース、iframe のコンテキストで使用されます。このページでは、各プロパティの概要と相違点について説明します。

出発地
送信元の構造。

「送信元」は、スキームHTTPHTTPS などのプロトコルとも呼ばれます)、ホスト名ポート(指定されている場合)を組み合わせたものです。たとえば、URL が https://www.example.com:443/foo の場合、「origin」は https://www.example.com:443 です。

「同一オリジン」と「クロスオリジン」

スキーム、ホスト名、ポートの組み合わせが同じウェブサイトは「同一オリジン」とみなされます。それ以外はすべて「クロスオリジン」とみなされます。

オリジン A オリジン B 「同一オリジン」か「クロスオリジン」か
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 同一オリジン: 完全一致
https://www.example.com 同一オリジン: 暗黙のポート番号(443)の一致

サイト

サイト(TLD+1)
サイトを構成する URL の構成要素。

.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)
eTLD を使用する URL の一部。

「same-site」と「cross-site」

同じスキームと同じ eTLD+1 のウェブサイトは、「同一サイト」と見なされます。スキームや eTLD+1 が異なるウェブサイトは「クロスサイト」です。

オリジン 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 同一サイト: ポートは重要ではない

「スキームのない同一サイト」

スキームのない同一サイト

HTTP が脆弱なチャネルとして使用されることを防ぐため、「same-site」の定義は、サイトの一部として URL スキームが含まれるように変更されました。スキーム比較のない以前の「同一サイト」のコンセプトは、「スキームレス同一サイト」と呼ばれるようになりました。たとえば、http://www.example.comhttps://www.example.com は、eTLD+1 部分のみが重要であり、スキームは考慮されないため、スキームのない同一サイトと見なされます。

オリジン 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」のいずれであるかを確認する方法

対応ブラウザ

  • 76
  • 79
  • 90
  • 16.4

ソース

最新のブラウザはすべて、Sec-Fetch-Site HTTP ヘッダーを使用してリクエストを送信します。ヘッダーは次のいずれかの値を取ります。

  • cross-site
  • same-site(スキームのある同一サイト)
  • same-origin
  • none

Sec-Fetch-Site の値を調べると、リクエストが同一サイト、同一オリジン、クロスサイトのいずれであるかを判断できます。

次の理由により、Sec-Fetch-Site ヘッダーの値が合理的に信頼できるものであると判断できます。