同一オリジンポリシー（SOP）

他のオリジンの情報を自由に読ませない

同一オリジンポリシーは、あるオリジンのページで動くJavaScriptが、別のオリジンの情報へ自由にアクセスすることを制限するブラウザのルールです。略称のSOPはSame-Origin Policyを表します。

たとえば利用者が銀行にログインしたまま見知らぬサイトを開いても、そのサイトのJavaScriptが銀行の非公開残高を自由に読み取れる状態にはしません。銀行が別オリジンへの読み取りを許可していなければ、ブラウザが応答内容をJavaScriptへ渡すことを制限します。

https://news.example のページで動くコードと https://bank.example のページは、ホストが違うため別オリジンです。どちらも同じ利用者のブラウザで開いていることは、読み取りの許可にはなりません。

別の場所から読み込んだJavaScriptでも、通常のscript要素でページ内に実行させると、そのページのオリジンで動きます。信頼していない外部スクリプトを銀行の画面に読み込むことは、その画面の情報へアクセスするコードを増やす判断になります。

SOPがあるからといって、別オリジンへのすべての送信が止まるわけではありません。リンクによる移動、画像の読み込み、条件を満たすフォーム送信などは、別オリジンを対象にできます。

たとえば悪意あるページが銀行の変更APIへフォームを送信し、Cookieの条件を満たすブラウザがログイン用Cookieをそのリクエストへ付けたとします。銀行が送信元や操作の意思を確認しなければ、応答を攻撃者が読めなくても設定変更は実行され得ます。これがCSRF対策を別途必要とする理由です。

応答内容の読み取り制限と、サーバーが操作を受理する条件は別々です。

正規の画面とAPIを別オリジンへ分ける構成では、API側がCORSで読み取りを許可できます。APIが返す許可ヘッダーをブラウザが調べ、条件が一致すれば、呼び出し元のJavaScriptへ応答を渡します。

別オリジンのウィンドウ同士で明示的に情報を渡すpostMessageという機能もあります。受信側は送信元のオリジンとメッセージ形式を調べます。オリジンの制限があるという理由だけで、アプリが自分で転送した情報まで安全になるわけではありません。

SOPはブラウザの制限なので、攻撃者が自分のプログラムからAPIを呼ぶこと自体は止めません。APIは認証情報と対象データへの権限を自分で調べる必要があります。

また、投稿した文字列が表示時にコードとして実行されるXSSが銀行のオリジン内で起きた場合、そのコードは銀行の画面と同じオリジンで動きます。残高APIへ利用者のブラウザからリクエストを送り、返された残高を読むことが可能になるため、SOPだけでは防げません。

確認問題：ブラウザのコンソールにCORSエラーが出たら、サーバーでは何も起きていないと言えるでしょうか。答えは言えません。プリフライトで本来の送信が止まった場合と、送信後の応答の読み取りが止まった場合があります。

自分の検証環境でNetwork欄とサーバーログを確認し、事前確認のOPTIONSだけが届いたのか、本来のリクエストも届いたのかを区別します。開発用にブラウザの保護を無効にしても、本番の許可設計は直りません。

未確認事項・限界

通信例・設定例・被害の例は、仕組みを理解するための仮定です。特定の製品で発生した事件を示すものではありません。ブラウザやサービス固有の設定は、利用する環境の公式資料でも確認してください。