サイバー攻撃手法・脆弱性分析重要度:★★★出題: AM2・PM1

同一オリジンポリシー (SOP) と CORS (オリジン間リソース共有)

どういつおりじんぽりしー / こーす / Same-Origin Policy (SOP) / Cross-Origin Resource Sharing (CORS)

ブラウザが異なるオリジン（スキーム・ホスト・ポート）間のリソース読取りを制限する基本防御機構（SOP）と、HTTPヘッダで安全に例外許可を与える仕組み（CORS）。

3行速習ポイント

オリジンは「スキーム（https://）＋ホスト名（example.com）＋ポート番号（:443）」の3つが完全一致する場合のみ同一と判定
SOPはクロスオリジンへのリクエスト『送信』自体は止めない場合があるが、レスポンスのJavaScriptからの『読取り』を厳格にブロックする
CORSでは Access-Control-Allow-Origin ヘッダで許可オリジンを指定し、プリフライトリクエスト（OPTIONSメソッド）で事前確認を行う

図解

図同一オリジンポリシー (SOP) と CORS プリフライト検証の仕組み

SOPの基本原則

同一オリジン判定（スキーム＋ホスト＋ポート番号）

3要素が完全一致する場合のみ同一オリジンとして読取りを許可

ブラウザの基本防御機構（SOP）により、異なるオリジンからfetch/XHRで取得したレスポンスデータのJavaScriptによる読取りをブロック

↕

事前安全性確認

プリフライトリクエスト (OPTIONSメソッドによる事前確認)

カスタムヘッダ付与時やPUT/DELETE時にブラウザが自動送信

本リクエスト送信前にOPTIONSメソッドで許可オリジン・許可メソッド・許可ヘッダをサーバに問い合わせ、未許可なら本リクエスト自体を中止（CSRF防止にも有効）

↕

安全な例外許可

Access-Control-Allow-Origin のホワイトリスト検証

信頼できるオリジンのみを明示的に許可してレスポンス開示

サーバ側でリクエストのOriginヘッダを厳格な許可リストと照合し、一致した正規フロントエンドオリジンのみにデータ読取りを許可

💡 Access-Control-Allow-Credentials: true の際に Origin ヘッダを無検証でオウム返しすると、罠サイトから認証付き情報を読み取られる

概要と本質

もしSOPが存在しなければ、利用者が悪意あるサイトを開いた瞬間、裏でログイン中のネットバンキングやWebメールのAPIをJavaScript（fetch/XHR）から呼び出し、口座残高やメール本文を自由に読み取って攻撃者サーバへ送信できてしまいます。CORS設定ミスはこのSOPの防壁を自ら解除してしまう危険な脆弱性です。

重要ポイント・コア概念

CORS設定の不備：Access-Control-Allow-Credentials: true とともに、リクエストの Origin ヘッダ値を無検証でそのまま Access-Control-Allow-Origin にオウム返しすると、任意の罠サイトから認証付きAPIレスポンスを読み取られる
プリフライトリクエスト（Preflight Request）：独自ヘッダ付与時やPUT/DELETE等の際、ブラウザが本リクエスト前に自動でOPTIONSメソッドを送りサーバ側の許可を確認する仕組み
CSRFとCORSの関係：単純リクエスト（Simple Request）はプリフライトなしで送信されるため、SOPがあっても状態変更リクエスト自体は届く（だからこそCSRFトークンやカスタムヘッダ検証が必要）

午後記述・情報セキュリティ対策での攻略ポイント

午後試験のWeb API問題で頻出。「オリジンが同一と判定される条件（スキーム・ホスト・ポートの3点一致）」「なぜ独自HTTPヘッダ（X-Requested-With等）を必須にするとCSRFを防げるのか（クロスオリジンから独自ヘッダを付けるとプリフライトが発生しCORSで遮断されるため）」は極めて重要な論理です。