同一オリジンとは？判定条件と同一オリジンポリシーが止める操作をChromeで実測

フロントエンドからAPIを呼んでTypeError: Failed to fetchになったとき、あるいはiframeの中身をJavaScriptから触ろうとしてSecurityErrorが出たとき、まず確かめるのが「同一オリジンかどうか」です。同一オリジンの判定条件は3つしかありませんが、何が止まり何が止まらないかは仕様ごとに散らばっています。この記事では判定条件を確定させたうえで、同一オリジンポリシー（Same-Origin Policy、SOP）の挙動をChrome 155で2つのオリジンを立てて実測した結果とあわせて整理します。

まとめ

• 同一オリジンとはスキーム・ホスト・ポートの3つがすべて一致する状態です。パスやクエリは判定に関係しません。
• httpとhttps、example.comとwww.example.com、ポート80と8080は、いずれも別オリジンです。
• SOPが止めるのは主に応答の読み取りです。実測でも、CORS許可のないfetchはTypeErrorで失敗した一方、リクエスト自体はサーバーに届いていました。フォームのPOSTも届きます。だからSOPだけではCSRFを防げません。
• allow-same-originを指定していないsandbox付きのiframeは不透明なオリジン（"null"）になり、localStorageにも触れません。allow-same-originとallow-scriptsを同一オリジンの文書に同時に与えると、中からsandbox属性を外せます（実測で成功）。
• same-originという値はCOOP・CORP・X-Frame-Options・Sec-Fetch-Siteなどに登場し、守る対象がそれぞれ違います。COOPは安全なコンテキスト（HTTPSやlocalhost）のページでしか処理されず、Sec-Fetch-Siteはリクエスト先がHTTPSなど潜在的に信頼できるURLのときだけ付きます。
• document.domainへの代入はChrome 115以降、安全なコンテキストでは既定で例外を出さずに無視されます（Origin-Agent-Cluster: ?0で戻せる）。非安全なHTTPのページでは実測で代入が効きましたが、この挙動に頼らずpostMessageへ移行します。

同一オリジンとは：スキーム・ホスト・ポートの3点一致

オリジン（origin）とは、URLのうちスキーム・ホスト・ポートの3要素を取り出した組です。MDNの同一オリジンポリシーは「二つのページのプロトコル、ポート番号 (もしあれば)、ホストが等しい場合、両者のページは同じオリジンです」と定義しています。概念を独立した文書として定義したのはIETFのRFC 6454「The Web Origin Concept」（2011年12月）で、3.2節に「two URIs are part of the same origin if they have the same scheme, host, and port.」とあります。

同一オリジンの判定表：スキーム・ホスト・ポートの比較

http://store.company.com/dir/page.htmlを基準にした判定です（MDNの表に、つまずきやすい2行を補いました）。

既定ポートは省略されていても同じものとして扱われます。http://example.comとhttp://example.com:80は同一オリジンです。開発中にlocalhost:3000のフロントからlocalhost:8080のAPIを呼ぶ構成が別オリジンになるのは、ポートの行が理由です。

オリジンとサイトの違い：ポートとサブドメインを無視する単位

紛らわしいのがサイト（site）という単位です。サイトはスキームと登録可能ドメイン（eTLD+1）で判定され、サブドメインとポートの違いを無視します。https://app.example.comとhttps://api.example.comは別オリジンだが同一サイトです。登録可能ドメインは単純な末尾2ラベルではなく、URL StandardがPublic Suffix Listで求めると定めています。たとえばgithub.ioはpublic suffixなので、a.github.ioとb.github.ioは別サイトです。スキームを判定に含める「schemeful same-site」は、Chrome 89のリリース資料で全利用者への展開が告知されました。web.devの解説のとおり、http://example.comとhttps://example.comは別サイトです。

ブラウザはリクエストごとにこの関係をSec-Fetch-Siteヘッダーでサーバーへ伝えます。値はsame-origin・same-site・cross-site・none（アドレスバー入力などの直接操作）の4つです（Fetch Metadata）。後述の実測では、a.example.testのページからのリクエストに、同じホストへはsame-origin、b.example.testへはsame-site、other.testへはcross-siteが付きました。ただし仕様は「リクエスト先がpotentially trustworthy URLでなければ付けない」と定めており、素のHTTPで同じ実験をすると、このヘッダーは1件も付きませんでした。

CookieのSameSite属性もサイト単位の判定です。一方、Cookieが実際にどのホストへ送られるかはDomain・Path・Secure属性で決まり、Domainを省略したCookieは発行元のホストにだけ返ります。DOMやlocalStorageへのアクセスはオリジン単位なので、同じサイトでもサブドメインが違えば触れません。

不透明なオリジンとオリジンの継承：about:blank・srcdoc・data:

URLから素直に3要素を取れない文書もあります。HTML Standardのオリジン決定手順は、about:blankとsrcdocの文書には作成元のオリジンを継承させ、data:URLの文書には新しい不透明なオリジン（自分自身以外のどのオリジンとも一致しない内部値）を与えます。実測でも、srcなしのiframeとsrcdocのiframeは親と同じオリジンになり中のDOMを操作できました。data:text/html,...を読み込んだiframeはSecurityErrorで触れませんでした。

ほかに不透明なオリジンになる代表例が、sandbox属性付きのiframe（後述）と、file:///で開いたローカルファイルです。MDNは「現行のブラウザーでは、file:/// スキームを使用して読み込まれたファイルのオリジンは、通常、不透明なオリジンとして扱われます」と述べています。HTMLファイルをダブルクリックで開くとfetchが失敗し、http://localhost経由なら動くのはこのためです。

同一オリジンポリシーが止めるもの・止めないもの

SOPは「他オリジンとのやり取りを全部禁止する仕組み」ではありません。MDNはクロスオリジンのアクセスを、書き込み（リンク・リダイレクト・フォーム送信）は概して許可、埋め込み（画像・スクリプト・iframe）は概して許可、読み込みは一般に不許可、の3つに分けています。操作ごとに整理すると次のとおりです。

SOPだけではCSRFを防げない理由

表の2行目が決定的です。攻撃者のページに置かれたformが自社サイトへPOSTすること自体は、SOPでは止まりません。実測でも、別オリジンへ送ったフォームの本文amount=1000はそのままサーバーに届きました。そのリクエストにCookieが付くかどうかはSameSite属性で決まります。MDNは、未指定時にLaxを既定とするのは一部のブラウザで、そのブラウザでは発行から2分以内ならトップレベル遷移のクロスサイトPOSTにもCookieを含める互換措置があると注記しています。iframe内への送信やfetchに効く例外ではありません。CSRFは応答の読み取りを必要とせず、サーバーが攻撃者の意図した処理を実行すると成立するので、応答を読めないことは防御になりません。

CSRFにはトークン方式やSameSite属性といった別の対策が要ります。詳しくはCSRFトークンとは？仕組み・Double Submit CookieとSPAでの実装とXSSとCSRFの違いとは？仕組み・被害・対策を実装レベルで徹底比較で扱っています。同様に、XSSで自サイトに注入されたスクリプトはそのオリジンの正規スクリプトとして動くため、SOPの制限を受けません。ここを塞ぐのはコンテンツセキュリティポリシー（CSP）とは？nonce方式の設定とXSS防御の実装判断を解説で説明しているCSPです。

クロスオリジンでも触れるWindowのプロパティ

別オリジンのiframeやwindow.openで開いた窓のWindowオブジェクトは、完全に遮断されるわけではありません。HTML StandardのCrossOriginPropertiesが許可しているのは、window・self・location・close・closed・focus・blur・frames・length・top・opener・parent・postMessageの13項目です。Locationはhrefへの書き込みとreplace()だけが許可され、読み取りはできません。実測でも、別オリジンのiframeに対してcontentWindow.closedとlengthは読めた一方、contentWindow.location.hrefの読み取りとcontentWindow.documentの参照はSecurityErrorになり、contentDocumentはnullでした。

SOPの仕様上の位置づけ：RFC・HTML・Fetchの分担

SOPを「W3Cが定めた勧告」と説明する解説がありますが、正確ではありません。オリジンの概念はRFC 6454（IETF）が定義し、どの操作をどう制限するかはWHATWGのHTML StandardとFetch Standardに分散しています。Cookie・Web Storage・Service Workerなどは各仕様が個別に同一オリジン要件を持ちます。調べるときは、機能ごとにその仕様を当たるのが近道です。

Chrome 155での実測：3オリジン間のアクセス制限と送信結果

ここまでの線引きを、2026年10月18日にChrome 155.0.8059.82（headless）とpuppeteer-coreで確かめました。Node.jsのサーバー1台にa.example.test・b.example.test・other.testの3つのホスト名を向け、a.example.test:8001のページから他の2つへ操作を仕掛けています。サーバーは受け取ったリクエストをすべてログに残すので、「ブラウザで失敗した操作のリクエストがサーバーに届いたか」まで分かります。

# 以下はChrome起動時に渡す2つの引数の抜粋です。単独のシェルコマンドではありません。
--host-resolver-rules="MAP *.example.test 127.0.0.1, MAP other.test 127.0.0.1"
--unsafely-treat-insecure-origin-as-secure=http://a.example.test:8001,http://b.example.test:8001,http://other.test:8001

// a.example.test のページで実行。CORSヘッダーの無い b.example.test の JSON を読む
try {
  const r = await fetch("http://b.example.test:8001/data");
  console.log(await r.text());
} catch (e) {
  console.log(e.name, e.message); // => TypeError Failed to fetch
}
// サーバーログには GET /data（Origin: http://a.example.test:8001）が残る

表の右列がすべて「届いた」になっている点が、この実験でいちばん見てほしいところです。SOPもCORPもcanvasの汚染も、今回の条件では取得済みの応答や画素データへのアクセスを制限するため、リクエストは送信されました。ただし、CORSプリフライトが失敗すれば本リクエストは送られず、fetchのsame-originモードでも別オリジンへの送信は拒否されます。サーバーのアクセスログに正常な200が並んでいても、ブラウザ側ではエラーになっていることがある、ということです。CORSエラーの調査でサーバーログだけを見て「リクエストは成功している」と判断するのは誤りで、開発者ツールのコンソールを合わせて見る必要があります。

検証スクリプトとログは、HTTPのまま実行した場合と安全なコンテキストとして実行した場合の2通りを残しています。HTTPのままでは、後述のCOOPとSec-Fetch-Siteが効かず、document.domainの代入が通るという差が出ました。手元で再現するときは、どちらの条件で動かしているかを先に確かめてください。

同一オリジンが要求される主なAPIと、その代替

実装で詰まりやすいのは「このAPIは同一オリジンが必要か」という個別の判断です。

canvasは症状が分かりにくい例です。MDNのCORS enabled imageによると、CORS承認なしに他オリジンの画像を描いた時点でcanvasはtainted（汚染）状態になり、getImageData()・toBlob()・toDataURL()を呼ぶとSecurityErrorになります。画像の表示は成功するので、保存やフィルタ処理だけが落ちます。実測では、画像にcrossOrigin = "anonymous"を付け、サーバーがAccess-Control-Allow-Origin: *を返すようにしただけでtoDataURL()が通りました。

ServiceWorkerContainer.register()は、スクリプトURLとスコープが登録元と同一オリジンでなければSecurityErrorを投げます。別オリジンのCDN URLからの登録は成立しませんが、CDNが自オリジンのパスとして配信する構成なら登録できます。

iframeのsandboxとallow-same-origin

iframeにallow-same-originを含まないsandbox属性を付けると、中の文書は不透明なオリジンになります。MDNのiframe要素はallow-same-originについて「このトークンが使用されていない場合、リソースは同一オリジンポリシーに常に失敗する特別なオリジンからのものとして扱われます」と説明しています。実測では、同じサーバーから配信した文書でもsandbox="allow-scripts"を付けると、子のself.originは"null"になり、localStorage.setItem()とdocument.cookieの参照がどちらもSecurityErrorになりました。これはJavaScriptからのCookie・ストレージ参照の制限で、HTTPリクエストにCookieが付くかどうかはSameSite属性や第三者Cookieの設定で別に決まります。文書本来のオリジンを維持するトークンがallow-same-originです。

allow-scriptsとの同時指定でsandboxが外れる条件

MDNは「埋め込まれた文書のオリジンが埋め込み先のページと同じである場合、allow-scriptsとallow-same-originを同時に使用すると、埋め込まれた文書からsandbox属性を削除することができるようになるため、絶対に避けるべきです」と警告しています。実測でも、親と同一オリジンの文書に2つのトークンを与えると、子のwindow.frameElement.removeAttribute("sandbox")が成功し、親から見たsandbox属性はnullになりました。次に読み込み直した時点で制限は消えます。

<!-- 外部由来のコンテンツ：スクリプトは許すがオリジンは戻さない -->
<iframe src="https://untrusted.example.com/widget"
        sandbox="allow-scripts allow-popups"></iframe>

<!-- 危険：親と同一オリジンの文書なら sandbox を自分で外せる -->
<iframe src="/embed/editor"
        sandbox="allow-scripts allow-same-origin"></iframe>

自己解除が成立するのは、埋め込む文書が親と同一オリジンのときだけです。別オリジンの文書にallow-same-originを与えてもsandboxは外されませんが、その文書自身のCookieやストレージへのアクセスを許すことになります。判断の基準は次のとおりです。

• ユーザー投稿や外部提供のコンテンツは、allow-scriptsを付けてもallow-same-originは付けない。不透明なオリジンのまま動かす。
• 自オリジンの信頼できる文書にスクリプトと同一オリジンの両方が要るなら、sandboxで隔離する意味が薄いので設計を見直す。どうしても隔離したいなら、配信を別オリジン（サンドボックス用の別ドメイン）に移す。

HTML Standardが列挙するsandboxの値は、2026年10月18日時点でallow-same-originを含む13種です。MDNの一覧に載るallow-storage-access-by-user-activationはこの列挙に無く、Chrome 135から使えるallow-same-site-none-cookiesも標準外の値です（Privacy Sandboxの告知）。各値の役割とCookie分割の対処はiframeのsandbox属性とCookie分割の解説にまとめています。

same-originという値をとるヘッダー・属性の早見表

same-originという文字列は、SOPとは別に複数のヘッダーの設定値として使われます。名前は似ていますが守る対象が違います。

COOPによるポップアップとの参照分離

Cross-Origin-Opener-Policy（COOP）は、自分が開いた窓や自分を開いた窓と参照を共有するかを決めます。既定値はunsafe-noneです。実測では、same-originを返すページから別オリジンをwindow.openすると、1.5秒後のw.closedがtrueになり参照が切れました。unsafe-noneとsame-origin-allow-popupsではfalseのままです。OAuthの認可画面や決済画面をポップアップで開く構成はsame-originだと壊れるので、MDNはsame-origin-allow-popupsの用途を「when using a cross-origin service for OAuth or payments」と明記しています。

注意点として、HTML Standardの手順は非安全なコンテキストではCOOPを読まずに既定値を返します。実測でもHTTPのままでは3つの値すべてでfalseになり、差が出ませんでした。SharedArrayBufferなどに要るクロスオリジン分離は、COOPをsame-originにしたうえでCOEPをrequire-corp（またはcredentialless）にして初めて成立します。

CORPとX-Frame-Options：読み込み制御と埋め込み制御

Cross-Origin-Resource-Policy（CORP）はsame-site・same-origin・cross-originの3値で、same-originは他オリジンからのno-corsモードの読み込みを拒否します。CORSモードで取得し、サーバーがCORSを許可する場合は利用できます。実測の表のとおり画像はエラーになりますが、リクエストは届いています。直リンクによる帯域消費への対策にはなりません。

X-Frame-OptionsのSAMEORIGINは逆方向で、自分のページが他オリジンのフレームに埋め込まれるのを防ぎます。MDNの定義は「The document can only be embedded if all ancestor frames have the same origin as the page itself.」で、直近の親だけでなくすべての祖先フレームが対象です。実測では、同じオリジンからは表示され、b.example.testのページに埋め込むとフレームがchrome-error://chromewebdata/に置き換わりました。ALLOW-FROMは廃止済みなので、特定サイトにだけ許すならCSPのframe-ancestorsを使います。設定と検証手順はクリックジャッキングとは？frame-ancestorsで防ぐ実装と検証手順を解説にあります。

strict-origin-when-cross-origin：オリジン別のReferer送信範囲

Referrer-Policyのstrict-origin-when-cross-originは、ヘッダーを指定しないときの既定値です。MDNの互換性データでは、既定になったのはChrome 85・Firefox 87・Safari 15です。Referrer Policyの仕様によると、同一オリジンへのリクエストにはパスとクエリを含むURLを、クロスオリジンへのリクエストにはオリジンだけを送り、HTTPSからHTTPへ下がるときは送りません。

実測でも、http://a.example.test:8001/page?user=42のページから同じオリジンへのfetchにはReferer: http://a.example.test:8001/page?user=42が付き、b.example.test（同一サイト・別オリジン）へはReferer: http://a.example.test:8001/だけが付きました。判定はサイトではなくオリジン単位なので、サブドメイン間の遷移でもパスとクエリは渡りません。サブドメインをまたぐアクセス解析でRefererのパスが空になるのはこのためです。Refererの値を使った制御やアクセス解析への影響はリファラー（Referer / Referrer）とは？仕組み・リファラー制御と「リファラを有効にしてください」の対処で扱っています。

クロスオリジンで正しくやり取りする方法

SOPを緩めるのではなく、必要な通信だけを明示的に許可するのが現在の作法です。

CORSはサーバーがAccess-Control-Allow-Originなどで許可を宣言する仕組みで、プリフライトやエラーの読み方はCORSとは？仕組み・プリフライト・サーバー設定例・エラー解決を実装目線で解説で詳しく扱っています。JSONPはscriptタグが読み込み制限の対象外である性質を使った古い手法で、提供元に任意のスクリプト実行を許すため採用しません（JSONPとは？読み方・仕組みとCORSとの違い、fetchで使えない理由とXSS対策）。

postMessageの検証条件：オリジン・送信元・データ形式

送信時は宛先オリジンを指定し、受信時はevent.originを必ず確かめます。省くと任意のサイトから送られたメッセージを処理してしまいます。

// 送信側：宛先オリジンを明示する（"*" は使わない）
iframe.contentWindow.postMessage(
  { type: "updateUser", id: 42 },
  "https://app.example.com"
);

// 受信側：オリジン・送信元・データ形式を検証してから処理する
window.addEventListener("message", (event) => {
  if (event.origin !== "https://parent.example.com") return;
  if (event.source !== window.parent) return;
  if (event.data?.type !== "updateUser" || !Number.isInteger(event.data.id)) return;
  handle(event.data);
});

document.domainの制限：Chromeの既定動作と例外

かつてはdocument.domainに上位ドメインを代入し、サブドメイン間でオリジンを揃える方法がありました。Chrome for Developersのdocument.domain setter deprecationは「Starting in Chrome 115, websites will be unable to set document.domain」と告知し、継続が必要な場合の最終手段としてOrigin-Agent-Cluster: ?0レスポンスヘッダーを挙げています。HTML Standardのdocument.domainの手順も、オリジン単位のエージェントクラスタに属する文書では何もせずに戻ると定めています。

自己署名証明書のHTTPSで確かめると、Chrome 155ではa.example.testのページでdocument.domain = "example.test"を実行しても例外は出ず、値はa.example.testのままで、b.example.testのiframeにはSecurityErrorで触れませんでした。Origin-Agent-Cluster: ?0を両方の文書に付けると代入が効き、中のDOMを操作できました。ここまでは告知どおりです。

見落とされやすいのはHTTPのページです。同じ実験を素のHTTPで行うと、ヘッダーなしでも代入が効き、iframeの中に触れました。このときwindow.originAgentClusterはfalseでした。HTML Standardも、非安全なコンテキストではOrigin-Agent-Clusterヘッダーによる要求を無効にすると定めています。社内システムなどHTTPのままのサイトでは古いdocument.domainのコードが動き続け、HTTPSへ移行した日に突然サブドメイン間の連携が壊れる、という順番で問題が表に出ます。HTTPS化の前にpostMessageへ置き換えておくのが安全です。なお、Firefoxのmainブランチのソースでは既定でのsetter無効化の設定値はfalseで、ブラウザによって挙動が違う点にも注意が要ります。

SOP関連エラーの症状別原因と切り分け手順

コンソールに出るエラーは、原因ごとに文面が違います。

切り分けは、まず開発者ツールのネットワークタブでリクエストが実際に送信されているかを見ます。送信されて応答も返り、コンソールにCORS違反が出ているなら、読み取りだけが止められた状態です。リクエストが飛んでいないなら、プリフライトの失敗かCSPなど別の仕組みを疑います。

最後の行は2025年以降に増えた原因です。Chrome 142のリリースノートは、公開サイトからローカルネットワークやループバック（localhost）へのリクエストを許可プロンプトで制御するLocal Network Accessを導入したと記しています。利用者が許可しても、応答をJavaScriptで読むには通常どおりCORSの許可が要ります。プロンプトの拒否とCORS違反は別の問題として確かめます。

よくある質問

同一オリジンとはどういう意味ですか？

2つのURLのスキーム（httpかhttpsか）・ホスト・ポート番号の3つがすべて一致している状態です。パス・クエリ・フラグメントは判定に影響しません。example.comとwww.example.comは別オリジンで、既定ポート（httpは80、httpsは443）は省略されていても同じとみなされます。

同一オリジンポリシーの目的は何ですか？

あるオリジンのスクリプトが、別オリジンのリソースの中身を読み取れないようにすることです。これがないと、開いた悪意あるページのスクリプトが、同じブラウザで開いているWebメールやネットバンキングの内容を読めてしまいます。ただし送信と埋め込みは許可されているため、SOPの中心は読み取りの遮断です。

同一生成元ポリシーとは？

Same-Origin Policyの訳語のひとつで、同一オリジンポリシーと同じものです。「同一オリジンポリシー」「同一生成元ポリシー」「SOP」は意味の違いなく併用されています。Wikipedia日本語版が「同一生成元ポリシー」を項目名にしているため、この表記もよく見かけます。

「Config URL must be on same origin.」と表示されるのはなぜですか？

360度パノラマビューアのPannellumが出すエラーです。ブラウザの標準メッセージではありません。pannellum.htm?config=...の形で設定JSONを渡すスタンドアロン表示で、設定ファイルのURLのオリジンが表示ページと違うと、この文言を出して処理を止めます。ソースコードには「Prohibit cross-origin requests, to mitigate XSS risk」というコメントがあり、この判定は2026年2月のコミットで入り、2.5.6には無く2.5.7から含まれています。設定JSONをpannellum.htmと同じオリジンに置けば解消します。

ローカルのHTMLファイルでfetchが失敗するのはなぜですか？

file:///で開いたファイルのオリジンが、不透明なオリジンとして扱われるためです。同じフォルダのファイル同士でも同一オリジンとはみなされず、CORSエラーになることがあります（file URLの扱いは実装依存です）。python3 -m http.serverなどで簡易サーバーを立て、既定ポートのhttp://localhost:8000からHTMLと取得対象を配信します。別オリジンのAPIを呼ぶ場合は、別途CORSの許可が必要です。

関連記事

• CORSとは？仕組み・プリフライト・サーバー設定例・エラー解決を実装目線で解説
• コンテンツセキュリティポリシー（CSP）とは？nonce方式の設定とXSS防御の実装判断を解説
• クリックジャッキングとは？frame-ancestorsで防ぐ実装と検証手順を解説
• CSRFトークンとは？仕組み・Double Submit CookieとSPAでの実装
• XSSとCSRFの違いとは？仕組み・被害・対策を実装レベルで徹底比較