はじめに
Webブラウザが守る「境界線」と攻撃者が狙う“抜け道”
Webアプリのセキュリティを語るとき、必ず登場する存在──
それが Same-Origin Policy（SOP / 同一オリジンポリシー） です。
最初に結論を言うと、SOP は 「異なるオリジン同士で勝手にデータを読み取らせないためのブラウザの根本ルール」。
オリジンとは プロトコル + ホスト + ポート番号 の3点セットのこと。
これらがすべて一致した場合にのみ、ブラウザは “同じグループ” と判断し、DOM や Cookie や Storage へのアクセスを許可します。
Webの世界で言えば、SOP は “知らない家の冷蔵庫を勝手に開けるな” を徹底する警備員みたいなものです。
1. オリジンとは何か？
オリジンは以下の3つがすべて一致している必要があります。
| 項目 | 例 |
|---|---|
| プロトコル | http / https |
| ホスト | example.com / api.example.com |
| ポート | 80 / 443 / 3000 |
たとえば…
https://example.com:443
これは以下とはすべて 別オリジン になります：
2. SOP が保護する領域
ブラウザは、"別オリジンのページ" が以下の情報を例外なく触れないようにします：
DOM へのアクセス
他サイトの DOM を読み書きするのは完全に禁止。
Cookie（特に HttpOnly）
他サイトの Cookie を JS から盗むのを防止。
LocalStorage / SessionStorage
オリジン単位で隔離されているため、跨いでアクセス不可。
JS 実行環境（window オブジェクトなど）
別オリジンの window のプロパティを読み取るのはできない。
3. “送信はOK、読み取りはNG” という誤解ポイント
SOP を誤解しやすいポイントとして、
別オリジンに対してリクエストを送ること自体は許可されている
という点があります。
例えば：
<img src="https://bank.com/profile">
<script src="https://cdn.example.com/script.js"></script>
fetch("https://api.example.com/data")
これらの “送信” は基本的に自由です。
しかし…
レスポンス内容の読み取りだけは、SOP が厳しく禁止している。
だから、攻撃者が銀行サイトにリクエストを投げることはできても、
そのレスポンスを読んで残高を見ることはできません。
4. Cookie が自動添付される理由（CSRF が成立する根本）
SOP は レスポンスの読み取りを禁止するだけ なので、
- リクエスト送信
- Cookie などの credential 自動送信
は止めません。
例えば、被害者が bank.com にログイン中で、攻撃サイト evil.com を開いたとします。
<img src="https://bank.com/transfer?to=hacker&amount=1000">
このリクエストに 被害者のログイン Cookie が自動添付 されます。
その結果：
- 銀行APIには本物のユーザとしてアクセスされる
- 攻撃者はレスポンス内容は読めない（SOPがブロック）
- しかし操作は完了してしまう
→ これが CSRF（Cross-Site Request Forgery）の本質。
5. 攻撃者が SOP を破壊する方法
SOP が防げる攻撃は多いですが、万能ではありません。
攻撃者は SOP の“隙間”を探して突破を狙います。
① XSS（Cross-Site Scripting）
攻撃者のスクリプトが 被害サイトと同じオリジン内で実行される。
つまり SOP の制限は完全に無効化される。
XSS = “敵のスクリプトが家の中に入ってしまう” ので、警備員（SOP）はもう無力。
② CORS Misconfiguration
Access-Control-Allow-Origin: *
などの誤設定により、ブラウザがレスポンス読取を許可してしまう。
SOP の穴を 管理者が自ら開けてしまう パターン。
③ postMessage の誤った利用
Window 間通信を許可する API。
origin チェックを怠ると、機密データを盗み取られる。
④ Open Redirect → SOP 回避の踏み台
OAuth・SSRF・Token 盗難などの攻撃で利用される。
6. SOP と CORS の関係
よく混同される2つですが、関係は非常にシンプル。
- SOP → デフォルトで“ダメ”と決めるルール
- CORS → サーバが「このオリジンだけ特別に許可するよ」と示す仕組み
つまり…
CORS は SOP を補う“特別許可証”である。
誤った CORS 設定が致命的なのはこのため。
7.Mermaid 図で SOP を直感的に理解する
8. ベストプラクティス
- DOM ベース XSS を徹底的に防ぐ
- CORS を絶対にワイルドカードにしない
- Cookie は
SameSite=Lax/Strictを原則 - OAuth Redirect URL を固定し、ワイルドカード禁止
- postMessage には厳密な origin チェックを入れる
まとめ
- SOP は「異なるオリジン間のデータ読み取り」を禁止するブラウザの基本ルール
- DOM・Cookie・Storage などの読み取りがブロックされる
- リクエスト送信はできる（ただしレスポンス読めない）
- Cookie 自動送信が CSRF の原因
- 攻撃者は XSS / CORS / postMessage などで SOP をバイパスする