「同一サイト」と「同一オリジン」はよく引用される用語ですが、誤解されることも多い用語です。たとえば、ページ遷移、fetch()
リクエスト、Cookie、ポップアップの開く、埋め込みリソース、iframe のコンテキストで使用されます。このページでは、これらの機能の概要と、それぞれの違いについて説明します。
出発地

「オリジン」は、スキーム(プロトコルとも呼ばれます。HTTP や HTTPS など)、ホスト名、ポート(指定されている場合)の組み合わせです。たとえば、URL が https://www.example.com:443/foo
の場合、「オリジン」は https://www.example.com:443
です。
「同一オリジン」と「クロスオリジン」
スキーム、ホスト名、ポートの組み合わせが同じウェブサイトは「同じオリジン」と見なされます。それ以外はすべて「クロスオリジン」と見なされます。
送信元 A | 送信元 B | 「同一オリジン」と「クロスオリジン」 |
---|---|---|
https://www.example.com:443 | https://www.evil.com:443 | クロスオリジン: 異なるドメイン |
https://example.com:443 | クロスオリジン: 異なるサブドメイン | |
https://login.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)は、ルートゾーン データベースに登録されています。上の例の「site」は、スキーム、TLD、その直前にあるドメインの部分(TLD+1 と呼びます)の組み合わせです。
たとえば、URL が https://www.example.com:443/foo
の場合、「site」は https://example.com
です。
Public Suffix List と eTLD
.co.jp
や .github.io
などの要素を含むドメインの場合、.jp
や .io
を使用するだけでは「サイト」を特定できません。特定の TLD で登録可能なドメインのレベルをアルゴリズムによって決定することはできません。そのため、Public Suffix List では、有効な 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+1 が異なるウェブサイトは「クロスサイト」です。
送信元 A | 送信元 B | 「同一サイト」と「クロスサイト」 |
---|---|---|
https://www.example.com:443 | https://www.evil.com:443 | クロスサイト: 異なるドメイン |
https://login.example.com:443 | 同一サイト: サブドメインが異なる場合でも問題なし | |
http://www.example.com:443 | クロスサイト: 異なるスキーム | |
https://www.example.com:80 | 同一サイト: 異なるポートでも問題ない | |
https://www.example.com:443 | 同一サイト: 完全一致 | |
https://www.example.com | 同一サイト: ポートは関係ない |
「スキームなしの同一サイト」

「同じサイト内」の定義が変更され、HTTP が脆弱なチャネルとして使用されないように、URL スキームがサイトの一部として含まれるようになりました。スキームの比較なしの「同一サイト」という古いコンセプトは、「スキームなしの同一サイト」に名称が変更されました。たとえば、http://www.example.com
と https://www.example.com
はスキームレスの同一サイトと見なされますが、同一サイトではありません。これは、eTLD+1 部分のみが重要で、スキームは考慮されないためです。
送信元 A | 送信元 B | 「スキームなしの同一サイト」と「クロスサイト」のどちらですか? |
---|---|---|
https://www.example.com:443 | https://www.evil.com:443 | クロスサイト: 異なるドメイン |
https://login.example.com:443 | スキームなしの同一サイト: サブドメインが異なる場合でも問題なし | |
http://www.example.com:443 | スキームレス Same-Site: スキームが異なる場合でも問題なし | |
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-site
same-site
(スキームありの同一サイトを指す)same-origin
none
Sec-Fetch-Site
の値を調べて、リクエストが同一サイト、同一オリジン、またはクロスサイトのいずれであるかを判断できます。
Sec-Fetch-Site
ヘッダーの値は、次の理由から信頼できます。
Sec-
で始まる HTTP ヘッダーは JavaScript で変更できない- これらの見出しはブラウザによって常に設定されます。