なぜブラウザはクロスドメインリクエストをブロックするのか？
フロントエンド開発中に「Access-Control-Allow-Origin」エラーに遭遇したことはありませんか？これはシステムの不具合ではなく、ユーザー保護のための「同一生成元ポリシー（Same-Origin Policy, SOP）」によるものです。SOP は、異なるオリジン（プロトコル、ドメイン、ポートが異なる）からのリクエストが直接データにアクセスするのを制限します。
同一生成元ポリシーと CORS の核心的な違い
同一生成元ポリシーはブラウザのデフォルトの動作ですが、CORS（Cross-Origin Resource Sharing）は、安全な前提でサーバーが特定の外部ソースにデータアクセスを許可するための仕組みです。HTTP ヘッダーを介して、サーバーは許可するソースを明確に定義できます。
単純リクエストとプリフライトリクエストの判断基準
すべてのリクエストが複雑な CORS ハンドシェイクを必要とするわけではありません。HTTP メソッドとヘッダーの複雑さに応じて、ブラウザは「単純リクエスト」と「非単純リクエスト」を区別します。
| リクエストタイプ | 特徴 | プリフライト (Preflight) |
|---|---|---|
| 単純リクエスト | GET/POST、標準ヘッダーのみ | 不要 |
| 非単純リクエスト | カスタムヘッダーや PUT/DELETE を含む | 必要 (OPTIONS) |
プリフライトリクエストの仕組み
非単純リクエストの場合、ブラウザはまず OPTIONS リクエストをサーバーに送信し、「このリクエストを送信してよいか？」を尋ねます。サーバーは許可されたソースやメソッドを返し、それが承認された後にのみ実際のリクエストが送信されます。
よくある CORS 設定ミス
- Access-Control-Allow-Origin をワイルドカード（*）にし、認証情報（Credentials）を許可している。
- OPTIONS リクエストを正しく処理しておらず、プリフライトが失敗する。
- 必要な Access-Control-Allow-Headers が欠けている。
- すべてのソースを無制限に開放しており、クロスサイト攻撃のリスクがある。
API の CORS ヘッダーを正しく設定する方法
サーバーサイドの設定では「最小権限の原則」に従いましょう。アスタリスクではなく、許可された Origin を明示的に指定します。Cookie を送信する必要があるアプリでは、Access-Control-Allow-Credentials を true に設定し、Origin が * になっていないことを確認してください。
現代的な API 設計におけるセキュリティの考慮事項
CORS に加えて、Content-Security-Policy (CSP) や X-Content-Type-Options などの他のセキュリティヘッダーも併せて確認することをお勧めします。これらのメカニズムを統合することで、XSS やクロスサイトリクエストフォージェリのリスクを大幅に低減できます。