「同一サイト」と「同一オリジン」はしばしば引用されますが、用語は誤解されがちです。たとえば、ページの遷移、fetch() リクエスト、Cookie、ポップアップの表示、埋め込みリソース、iframe のコンテキストで使用されます。このページでは、各プロパティの概要と相違点について説明します。
出発地
「送信元」は、スキーム（HTTP や HTTPS などのプロトコルとも呼ばれます）、ホスト名、ポート（指定されている場合）を組み合わせたものです。たとえば、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）の一致 |
サイト
.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 | 「同一サイト」か「クロスサイト」か |
|---|---|---|
| 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.com と https://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」のいずれであるかを確認する方法
最新のブラウザはすべて、Sec-Fetch-Site HTTP ヘッダーを使用してリクエストを送信します。ヘッダーは次のいずれかの値を取ります。
cross-sitesame-site（スキームのある同一サイト）same-originnone
Sec-Fetch-Site の値を調べると、リクエストが同一サイト、同一オリジン、クロスサイトのいずれであるかを判断できます。
次の理由により、Sec-Fetch-Site ヘッダーの値が合理的に信頼できるものであると判断できます。
Sec-で始まる HTTP ヘッダーを JavaScript で変更することはできません- ブラウザは常にこれらの見出しを設定します。