同一オリジンポリシー（Same Origin Policy）（略称：SOP）は、ブラウザが「別のオリジン（スキーム・ホスト・ポートが異なる）」からの不正な読み取りを防ぐための基本ルールです。

本記事では、URLを分解しながら同一/別オリジンの判定例を整理し、クロスオリジンで何が起きるのかを図解します。さらに、fetch/XHRのレスポンスが読めない理由、iframeのDOM操作制限、localStorageやCanvasの制約など“できること・できないこと”を一覧化しています。

SOPについて詳しく知りたい方は、是非最後まで読んでみてください。

目次

• 同一オリジンポリシー（Same Origin Policy）とは？
  • 「同じオリジン」とは何か（スキーム・ホスト・ポート）
  • 何を防ぐ仕組み？（XSS / CSRF との関係）
• ブラウザは何を止めている？Same Origin Policyの仕組みを図解
  • ブラウザ内アクセスの禁止
  • ネットワーク越しアクセスの一部禁止
• 同一オリジンポリシーの制限範囲
  • 制限される代表例：fetch / XMLHttpRequest の「レスポンスが読めない」
  • 制限される代表例：DOMアクセス（iframe内ドキュメントなど）
  • 制限される代表例：Web Storage（localStorage/sessionStorage）
  • 制限される代表例：Canvas（taint で読み取り不可）
  • 制限されない代表例：画像・CSS・script読み込み（でも注意点あり）
• 「なぜ必要？」を攻撃視点で理解：SOPが守るもの
• まとめ

同一オリジンポリシー（Same Origin Policy）とは？

同一オリジンポリシー（Same Origin Policy）とは、ブラウザが「同じオリジン（スキーム・ホスト・ポートの組み合わせ）」以外のWebページから、重要な情報を勝手に読み取れないようにする安全ルールです。

「同じオリジン」とは何か（スキーム・ホスト・ポート）

例：https://shop.example.com:443/cart

上のURLのうち、https がスキーム（通信方式）です。httpとhttpsが違うだけでも別オリジンになります。

shop.example.comがホスト（接続先のドメイン名）で、example.comとapi.example.comのようにサブドメインが違えば別オリジンです。

443 がポート（接続口番号）で、同じホストでも 443 と 8080 のように番号が違えば別オリジン扱いです。

つまり「同じオリジン」とは、スキーム・ホスト・ポートの3要素がすべて一致している状態を指し、ドメイン文字列が似ていても3要素のどれかが違えば別オリジンになります。

何を防ぐ仕組み？（XSS / CSRF との関係）

同一オリジンポリシーは、別オリジン（スキーム＝通信方式、ホスト＝接続先ドメイン、ポート＝番号の組み合わせが違う）から、他サイトの情報を勝手に「読み取る」ことを防ぐ仕組みです。

これによりXSS攻撃で悪意あるJavaScriptが動いても、基本的にそのオリジン内のDOMやAPIレスポンス、Storageにしか触れられず、被害の横展開を抑えられます。

一方CSRF攻撃は「送信はできる」点を突く攻撃で、SOPだけでは防げないため、SameSiteやCSRFトークンなど別の対策が必要になります。

参考記事①：トークン方式のCSRF対策を図解：フォーム送信の安全化手順
参考記事②：SameSite属性とは？Cookie送信制御でCSRFを防ぐ仕組み

ブラウザは何を止めている？Same Origin Policyの仕組みを図解

ある２つのWebリソースのOriginが異なるとき（Cross Origin）、ブラウザはCross Originなリソースへのブラウザ内アクセスを禁止し、Cross Originなリソースへのネットワーク越しのアクセスについても部分的に禁止します。

ブラウザ内アクセスの禁止

ブラウザ内アクセスとは、サイトAで動くJavaScriptが、別オリジンのサイトBの情報をブラウザ内部で読み取る行為を指します。

具体的には、iframe内のDOM参照、localStorage/sessionStorageの参照、そしてfetch/XMLHttpRequestで取得したレスポンス本文を読む操作が該当します（図の赤×）。

なお、サイトAのサーバからサイトBのサーバへ行うサーバ間通信はブラウザの制約外のため、Same Origin Policyの対象ではありません。

ネットワーク越しアクセスの一部禁止

ネットワーク越しアクセスとは、ブラウザがHTTP通信を発生させて外部リソースを取得・送信する行為（ページ遷移、フォーム送信、リソース読み込みなど）を指します。

このうちSame Origin Policyが特に制限するのが、JavaScriptから発行するfetch / XMLHttpRequest による他オリジン通信です。

サイトAのスクリプトがサイトBのサーバへリクエストを出してデータを取得しようとしても、オリジンが異なる場合はブラウザが安全のために制約をかけ、意図した形で利用できない（またはエラーになる）ことがあります。

同一オリジンポリシーの制限範囲

同一オリジンポリシー（Same Origin Policy）で制限される代表例を紹介します。

制限される代表例：fetch / XMLHttpRequest の「レスポンスが読めない」

同一オリジンでないURLに対してJSから取得を試みると、通信は起きても、レスポンス本文をJSに渡さない（読めない）状態になります。

// 例：サイトA上のJSから、別オリジンのAPIを取得
fetch("https://api.other.example/data")
  .then(r => r.text())   // ← ここで「読めない」扱いになりやすい
  .then(console.log)
  .catch(console.error);

// XMLHttpRequestでも同様（responseTextが利用できない/例外）
const xhr = new XMLHttpRequest();
xhr.open("GET", "https://api.other.example/data");
xhr.onload = () => console.log(xhr.responseText);
xhr.onerror = (e) => console.log("error", e);
xhr.send();

制限される代表例：DOMアクセス（iframe内ドキュメントなど）

他オリジンのページを<iframe>で埋め込めても、中身のDOM（document）を読む/操作するのはブラウザがブロックします。

<iframe id="b" src="https://site-b.example/"></iframe>
<script>
  const iframe = document.getElementById("b");
  // 他オリジンだとここで例外（SecurityError）になりやすい
  console.log(iframe.contentWindow.document.body.innerText);
</script>

制限される代表例：Web Storage（localStorage/sessionStorage）

Web Storageはオリジン単位で完全分離されています。
つまりサイトAのJSは、サイトBのlocalStorage/sessionStorage領域そのものにアクセスできません。

// これは「今のオリジン（サイトA）」のStorageしか触れない
localStorage.setItem("token", "A-ONLY");
console.log(localStorage.getItem("token")); // "A-ONLY"

// サイトBの localStorage を直接指定して読む、といったことはできない
// （BのURLを渡して読むAPIがそもそも存在しない）

制限される代表例：Canvas（taint で読み取り不可）

他オリジン画像をCanvasに描画すると、Canvasが**taint（汚染）**され、ピクセル読み取り系APIが禁止されます。
画像の表示はできても、中身（画素）を抜き出せないという制限です。

<canvas id="c" width="300" height="150"></canvas>
<script>
  const ctx = document.getElementById("c").getContext("2d");
  const img = new Image();
  img.src = "https://other.example/image.png"; // 他オリジン画像
  img.onload = () => {
    ctx.drawImage(img, 0, 0);
    // ここが禁止されやすい（SecurityError）
    console.log(ctx.getImageData(0, 0, 1, 1).data);
  };
</script>

制限されない代表例：画像・CSS・script読み込み（でも注意点あり）

<img>/<link rel="stylesheet">/<script src>は、別オリジンでも読み込み自体は可能です（「埋め込み」用途）。
ただし「読み込んだ内容をJSで覗く」「実行による影響」には注意点があります。

<!-- 画像は表示できる -->
<img src="https://other.example/logo.png">

<!-- CSSも適用できる -->
<link rel="stylesheet" href="https://cdn.example/style.css">

<!-- scriptは読み込める＝“実行される”ので信頼が重要 -->
<script src="https://cdn.example/lib.js"></script>

CSSの中身をJSで読む（stylesheet.cssRulesなど）ことは、他オリジンだと例外になることがあります。

// 他オリジンのstylesheetだとSecurityErrorになりやすい
console.log(document.styleSheets[0].cssRules);

「なぜ必要？」を攻撃視点で理解：SOPが守るもの

攻撃者が用意したサイトをあなたが開くと、そのページ上のJavaScriptは「あなたのブラウザの権限」で動きます。もし同一オリジンポリシー（SOP）が無ければ、攻撃サイトのスクリプトがネットバンクやSNSなど別サイトのページ内容、ログイン後の個人情報、過去の操作結果まで読み取れてしまいます。

SOPは、オリジンが違うサイト同士で「中身を読む」行為（DOM参照、Web Storage参照、fetch/XHRの結果利用など）を制限し、ブラウザに保存された認証情報やユーザーのセッションを“のぞき見”されるのを防ぎます。これにより、クリック一つで情報が抜かれるような被害を起こしにくくしています。

まとめ

本記事の内容をまとめると以下の通りです。

• SOPは、別オリジン（スキーム・ホスト・ポートが異なる）から他サイトの情報を勝手に読み取るのを防ぐ、ブラウザの基本ルール。
• 同一/別オリジンは、URLのスキーム・ホスト・ポートがすべて一致するかで判定される。
• クロスオリジンでは、fetch/XHRのレスポンス利用、iframe内DOM参照、Web Storage参照、Canvasのピクセル読み取りなど「中身を読む」操作が制限される。
• <img>/CSS/外部scriptの読み込みは基本可能だが、読み取れない・実行されるなどの注意点がある。
• XSSで悪意あるJSが動いても被害の横展開を抑えやすい一方、CSRFはSOPだけでは防げないためSameSiteやCSRFトークンが必要。

同一オリジンポリシーを正しく設定するようにしましょう。