Hello there, ('ω')ノ
🔒 同一生成元ポリシーは便利だけど不便？
同一生成元ポリシー（Same-Origin Policy, SOP）は、異なるオリジン間でのデータアクセスを制限する強力なセキュリティ機構です。しかし、近年のモダンなWebアプリケーションでは、以下のような正当な理由で他のオリジンとの通信が必要になるケースも増えています：
- メインサイトからサブドメインのAPIにアクセスしたい（例：
example.com→api.example.com） - サードパーティサービス（決済、CDN、チャット）との連携
- フロントエンドとバックエンドの分離されたSPA（Single Page Application）構成
このような場面で、同一生成元ポリシーが「厳しすぎる」となるのです。
🌉 CORSでポリシーを“安全に”緩和する
この問題を解決するのが CORS（Cross-Origin Resource Sharing：クロスオリジン・リソース共有） です。CORSはサーバーとブラウザ間でHTTPヘッダーを用いたやり取りを行い、特定のオリジンに対してのみアクセスを許可する柔軟な仕組みです。
📡 CORSの基本的な流れ
ブラウザがクロスオリジンリクエストを送信
- たとえばJavaScriptで
fetch('https://api.example.com/data')を実行
- たとえばJavaScriptで
対象サーバーがレスポンスヘッダーで許可を表明
Access-Control-Allow-Origin: https://your-website.com
- ヘッダーに一致していれば、ブラウザはレスポンスをJavaScriptから参照可能にする
🧾 よく使われるCORSヘッダー
Access-Control-Allow-Origin: 許可するオリジンAccess-Control-Allow-Credentials: 認証情報（クッキーなど）を許可するかAccess-Control-Allow-Methods: 許可するHTTPメソッド（GET, POSTなど）Access-Control-Allow-Headers: 許可するリクエストヘッダー（Content-Typeなど）Access-Control-Expose-Headers: JavaScriptでアクセス可能なレスポンスヘッダーAccess-Control-Max-Age: プリフライト結果のキャッシュ期間（秒）
🔁 プリフライトリクエストとは？
「安全でない」クロスオリジンリクエスト（例：PUTやDELETEメソッド、カスタムヘッダー付きPOSTなど）は、実際のリクエストの前にOPTIONSリクエストを送信して、サーバーがそのリクエストを許可しているか確認します。これをプリフライトリクエストと呼びます。
🔐 セキュリティ上の注意点
CORSは便利ですが、設定を誤ると危険です：
Access-Control-Allow-Origin: *（ワイルドカード）は、認証付きのリクエストには使ってはいけません。Access-Control-Allow-Credentials: trueを使うときは、Allow-Originにワイルドカードを使わず、明示的なドメイン指定が必要です。- ヘッダーを信頼できないクライアントや環境で制御してはいけません。
✅ まとめ
- 同一生成元ポリシーは強力だが柔軟性に欠ける。
- CORSは信頼できるオリジンに対してのみ、アクセスを安全に許可できる手段。
- HTTPヘッダーを適切に設定することで、安全なクロスオリジン通信が可能になる。
- CORSの誤設定は重大なセキュリティリスクにつながるため、慎重に設定すること。
ペネトレーションテストでは、CORS設定の誤りを狙った攻撃（たとえば認証付きAPIが外部に公開されている）も非常に重要なチェックポイントです。
Best regards, (^^ゞ
