CORS の内部動作とプリフライト判定

何を守る仕組みなのか

CORS（Cross-Origin Resource Sharing）は、ブラウザの根幹である同一オリジンポリシー（SOP）を、サーバーの許可宣言に基づいて部分的に緩和するための規格です。オリジンとは スキーム + ホスト + ポート の三つ組で、https://app.example:443 と https://api.example:443 はホストが違うので別オリジンです。

ここで最初に押さえるべき本質は、CORS はリクエストの送信そのものを止めないということです。クロスオリジンの fetch でも、リクエストは多くの場合サーバーに到達し、サーバーは処理してレスポンスを返します。ブラウザは返ってきたレスポンスを見て、「このオリジンに読ませてよい」とサーバーが明示していなければ、レスポンスを JS から読めないように遮断するだけです。つまり保護対象は「攻撃者サイトが、被害者の権限で別オリジンのレスポンス本文を盗み読むこと」であって、書き込み（副作用）を止めるのは CSRF 対策の領分です。両者を混同すると設計を誤ります。

単純リクエストとプリフライトの分岐

ブラウザはクロスオリジン要求を、**プリフライト不要の「単純リクエスト（safelisted request）」**か、事前確認が要るリクエストかに振り分けます。すべての条件を満たすものだけが単純リクエストです。

実務で最もよく踏むのが Content-Type です。fetch で JSON を送る Content-Type: application/json は safelisted に含まれないため、それだけでプリフライトが発生します。逆に言えば、HTML の <form> が application/x-www-form-urlencoded で POST できてしまうのは単純リクエストだからで、これが CORS だけでは CSRF を防げない理由でもあります。

プリフライトの往復を読み解く

プリフライトは、本番リクエストの前にブラウザが自動で投げる OPTIONS の問い合わせです。「これからこのメソッドとこのヘッダで送りたいが、許すか」をサーバーに尋ねます。

OPTIONS /orders HTTP/1.1
Host: api.example
Origin: https://app.example
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: authorization, content-type

サーバーがこれを許可するなら、対応するヘッダを返します。

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.example
Access-Control-Allow-Methods: GET, PUT, DELETE
Access-Control-Allow-Headers: Authorization, Content-Type
Access-Control-Max-Age: 600

ブラウザの評価アルゴリズムは厳密です。Access-Control-Request-Method の値が Allow-Methods の集合（例 {GET, PUT, DELETE}）に含まれ、かつ Access-Control-Request-Headers に挙げた各ヘッダがすべて Allow-Headers に含まれて初めて通過します。一つでも欠ければプリフライトは失敗し、本番リクエストは送られません。Access-Control-Max-Age はこのプリフライト結果をブラウザがキャッシュしてよい秒数で、同条件の連続呼び出しで OPTIONS の往復を省けます（上限はブラウザ依存で、Chromium 系は約 2 時間）。

credentials 付き要求とワイルドカードの制約

Cookie やクライアント証明書、Authorization ヘッダを伴う「資格情報付き要求」では、CORS の制約が一段厳しくなります。ブラウザは fetch(..., { credentials: 'include' }) のときだけ Cookie を送り、レスポンス側に Access-Control-Allow-Credentials: true が無ければレスポンスを遮断します。

決定的な制約は、credentials 付き要求では Access-Control-Allow-Origin: * が無効になることです。同様に Allow-Headers: * や Allow-Methods: * のワイルドカードも、credentials 付きではリテラルの * という文字としてしか解釈されません。許可するなら具体的なオリジン文字列をそのまま返すしかありません。

* が使えないため、複数オリジンを許可したいサーバーは「リクエストの Origin を読み、許可リストに含まれていればその値をそのまま Access-Control-Allow-Origin に反射する」という実装を取ります。ここで重要なのが Vary: Origin です。レスポンスがオリジンによって変わるのに Vary を付けないと、CDN や共有キャッシュがあるオリジン向けの Allow-Origin を別オリジンに配ってしまい、キャッシュ汚染で許可が漏れます。

誤設定による情報漏洩

CORS の事故の大半は、緩和を「広げすぎる」ことで起きます。レスポンスを読めるのは攻撃者のスクリプトであり、被害者の Cookie で認証された状態なら、その応答（個人情報・トークン等）がそのまま盗まれます。

// 危険：どんなオリジンでも許可してしまう
res.setHeader('Access-Control-Allow-Origin', req.headers.origin);
res.setHeader('Access-Control-Allow-Credentials', 'true');

誤設定のパターンと対策を整理します。

許可判定では部分一致を絶対に使わないことが鉄則です。origin.endsWith('app.example') のような実装は app.example.attacker.com を、origin.startsWith('https://app.example') は https://app.example.evil.com を通してしまいます。ホスト名を完全一致で照合してください。

const allowed = new Set(['https://app.example', 'https://admin.example']);
const origin = req.headers.origin;
if (origin && allowed.has(origin)) {       // 完全一致のみ
  res.setHeader('Access-Control-Allow-Origin', origin);
  res.setHeader('Access-Control-Allow-Credentials', 'true');
  res.setHeader('Vary', 'Origin');         // キャッシュ汚染の防止
}

全体像の中での位置づけ

CORS は「ブラウザがレスポンスを読ませてよいか」を制御する一機構にすぎません。サーバーへの到達やヘッダ全般の安全設定は セキュリティヘッダ の領域であり、レスポンスを読まれた場合の被害は XSS と地続きです。一方、サーバー側が外部に対して内部リソースへリクエストを飛ばしてしまう SSRF は CORS とは別レイヤの問題で、CORS では防げません。CORS は読み取り許可の宣言、CSRF はトークンによる書き込み保護——役割を分けて、両者を重ねて設計するのが正解です。