CORS

本文约需 2 分钟阅读

CORS (Cross-Origin Resource Sharing) とは、ブラウザが異なるオリジン (ドメイン、ポート、プロトコルの組み合わせ) のサーバーにリクエストを送信する際のアクセス制御の仕組みです。 2014 年に W3C で勧告され、現在は全主要ブラウザが実装しています。 Web アプリケーションがフロントエンドとバックエンドを別ドメインで運用するアーキテクチャが一般化した現在、 CORS の正しい理解と設定は Web 開発者にとって必須のスキルです。CSRF やXSS と密接に関連するセキュリティ機構でもあります。

同一オリジンポリシー (SOP) との関係

CORS を理解するには、まず同一オリジンポリシー (Same-Origin Policy) を知る必要があります。 SOP は 1995 年に Netscape Navigator 2.0 で導入されたブラウザのセキュリティモデルで、「あるオリジンから読み込まれたスクリプトは、別のオリジンのリソースにアクセスできない」という制約です。

オリジンの構成要素:

https://example.com:443/path
スキーム: httpsホスト: example.comポート: 443
この 3 つが全て一致する場合のみ「同一オリジン」。パスは関係ない。

https://example.com/page1 → https://example.com/page2 (同一)

https://example.com → http://example.com (スキームが異なる)

https://example.com → https://api.example.com (ホストが異なる)

https://example.com → https://example.com:8080 (ポートが異なる)

SOP がなければ、悪意のあるサイトが銀行サイトの API を呼び出してユーザーの口座情報を取得するといった攻撃が容易に成立します。 CORS は、この SOP の制約を安全に緩和するための仕組みです。サーバーが「このオリジンからのリクエストは許可する」と明示的に宣言することで、正当なクロスオリジン通信を可能にします。

プリフライトリクエスト (OPTIONS) の仕組み

ブラウザは、特定の条件を満たすクロスオリジンリクエストを送信する前に、 OPTIONS メソッドで「プリフライトリクエスト」を送信します。これはサーバーに「このリクエストを受け入れるか?」と事前確認する仕組みです。

ブラウザが OPTIONS を送信サーバーが許可ヘッダーを返すブラウザが許可を確認本来のリクエストを送信サーバーがレスポンスを返す

プリフライトが発生する条件は、 PUT / DELETE / PATCH メソッドの使用、Content-Type: application/json などのカスタムヘッダーの送信、認証情報 (Cookie) の送信などです。 GET リクエストでカスタムヘッダーがなければ「単純リクエスト」として扱われ、プリフライトは省略されます。

主要な CORS レスポンスヘッダー

ヘッダー	役割	注意点
Access-Control-Allow-Origin	許可するオリジンを指定	ワイルドカード (*) は認証情報付きリクエストと併用不可
Access-Control-Allow-Methods	許可する HTTP メソッドを列挙	プリフライトレスポンスで返す
Access-Control-Allow-Headers	許可するリクエストヘッダーを列挙	Authorization 等のカスタムヘッダーを明示する
Access-Control-Allow-Credentials	Cookie 等の認証情報の送信を許可	true の場合、 Allow-Origin に * は使えない
Access-Control-Max-Age	プリフライト結果のキャッシュ秒数	長すぎると設定変更の反映が遅れる

よくある誤設定とそのリスク

Access-Control-Allow-Origin: *

全オリジンを許可する設定。公開 API には適切だが、認証が必要な API に設定すると、悪意のあるサイトからユーザーのデータを取得される。 Credentials と併用できないため、 Cookie 認証の API では機能しない。

Origin ヘッダーの無検証な反射

リクエストの Origin ヘッダーの値をそのまま Allow-Origin に返す実装。実質的に全オリジンを許可しているのと同じだが、 Credentials: true と併用できてしまうため、 * よりも危険。

null オリジンの許可

Access-Control-Allow-Origin: null を設定すると、 sandboxed iframe やローカルファイルからのリクエストが許可される。攻撃者が iframe 内から API を呼び出す攻撃に悪用される。

CORS と CSRF の関係

CORS と CSRF は混同されがちですが、防御する対象が異なります。 CORS はブラウザがレスポンスの読み取りを制御する仕組みであり、リクエストの送信自体は (単純リクエストの場合) ブロックしません。つまり、 CORS を正しく設定しても、 CSRF 攻撃によるリクエスト送信は防げない場合があります。 CSRF 対策にはトークン方式や SameSite Cookie 属性など、別の防御層が必要です。CSP やSSL/TLS と組み合わせた多層防御が重要です。

API キーを使用するサービスでは、 CORS の設定ミスが API キーの漏洩につながるケースもあります。ブラウザ拡張機能のセキュリティ、API キー管理のベストプラクティス、スタートアップのセキュリティチェックリストもあわせて参照してください。Web API セキュリティの関連書籍 (Amazon)で実装パターンを学ぶことを推奨します。