CORSとは？仕組みとプリフライト、危ない設定と安全な書き方

CORS（Cross-Origin Resource Sharing、オリジン間リソース共有）は、別のオリジンから読み込まれたページのスクリプトに、自分のサーバーのレスポンスを読ませてよいかをHTTPヘッダーで伝える仕組みです。ブラウザの同一オリジンポリシーを、サーバーが明示した範囲だけゆるめます。CORSは守りを強める仕組みではなく、制限を外す仕組みなので、許可する範囲を広げすぎると情報を読み取られる原因になります。

CORSとは

オリジンは、スキーム（https など）、ホスト名、ポート番号の組み合わせです。MDNによると、fetch() や XMLHttpRequest は同一オリジンポリシーに従い、他のオリジンのレスポンスは、そのレスポンスに適切なCORSヘッダーが含まれている場合にしか読み取れません。

たとえば https://app.example.com のページから https://api.example.com のAPIを呼ぶと、ホスト名が違うので別オリジンです。APIのレスポンスに次のヘッダーがあれば、ブラウザはスクリプトにレスポンスを渡します。

Access-Control-Allow-Origin: https://app.example.com

OWASPのHTML5セキュリティチートシートは、CORSはCSRFを防ぐものではないとして、CSRF対策は別に必要だと注意しています。CSRFの対策はCSRFの解説にまとめています。

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

CORSのリクエストは、ブラウザが事前確認をせずに送る「単純リクエスト」と、先に OPTIONS メソッドで確認する「プリフライトリクエスト」に分かれます。MDNが示す単純リクエストの主な条件は次のとおりです。

JSONを Content-Type: application/json で送るリクエストや、Authorization などの独自ヘッダーを付けたリクエストは、単純リクエストの条件を満たさないのでプリフライトが送られます。

プリフライトへのレスポンスの例です。Access-Control-Max-Age は、プリフライトの結果をキャッシュしてよい秒数です。MDNによると、指定しない場合の既定値は5秒で、ブラウザごとの上限を超える値を指定すると上限が優先されます。

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Content-Type
Access-Control-Max-Age: 86400
Vary: Origin

資格情報を伴うリクエストの制約

Cookieなどの資格情報は、既定ではオリジン間のリクエストで送られません。送るには、fetch() なら credentials: "include"、XMLHttpRequest なら withCredentials = true を指定します。

// フロントエンド：Cookieを付けて別オリジンのAPIを呼ぶ
const res = await fetch("https://api.example.com/me", {
  credentials: "include",
});

このときサーバーは Access-Control-Allow-Credentials: true を返す必要があり、返さない場合、ブラウザはレスポンスをスクリプトに渡しません。さらにMDNは、資格情報付きのリクエストに応答するときは次のヘッダーで * を使ってはならないとしています。

この制約があるため、「どのオリジンからでもCookie付きで読めるようにしたい」と考えて、受け取った Origin をそのまま返す実装が生まれがちです。これが次に挙げる危ない設定の代表です。

危ないCORS設定

OWASP Top 10:2025のA01「Broken Access Control」は、CORSの設定ミスによって、許可されていない、または信頼できないオリジンからAPIにアクセスできてしまうことを例に挙げています。PortSwiggerのWeb Security Academyは、よくある設定ミスとして次を挙げています。

たとえば、Cookieで認証するAPIが次のように応答していると、攻撃者のサイトに誘導されたログイン中の利用者のブラウザから、そのAPIのレスポンスを読み取られます。

// 危険な例：受け取ったOriginをそのまま返している
app.use((req, res, next) => {
  res.setHeader("Access-Control-Allow-Origin", req.headers.origin);
  res.setHeader("Access-Control-Allow-Credentials", "true");
  next();
});

文字列の一部だけを確かめる判定も同じように危険です。origin.endsWith("example.com") は attacker-example.com を通し、origin.startsWith("https://example.com") は https://example.com.attacker.net を通します。

安全な設定の書き方

許可するオリジンを一覧で持ち、受け取った Origin と完全一致したときだけ返します。MDNは、オリジンによって返す値を変える場合は Vary: Origin を付けるよう説明しています。付けないと、キャッシュが別のオリジン向けのレスポンスを返してしまうおそれがあります。

// 安全な例：許可リストと完全一致したオリジンだけを返す
const allowedOrigins = new Set([
  "https://app.example.com",
  "https://admin.example.com",
]);

app.use((req, res, next) => {
  const origin = req.headers.origin;
  res.append("Vary", "Origin");

  if (origin && allowedOrigins.has(origin)) {
    res.setHeader("Access-Control-Allow-Origin", origin);
    res.setHeader("Access-Control-Allow-Credentials", "true");
  }

  if (req.method === "OPTIONS") {
    res.setHeader("Access-Control-Allow-Methods", "GET, POST");
    res.setHeader("Access-Control-Allow-Headers", "Content-Type");
    return res.sendStatus(204);
  }

  next();
});

1. CORSが本当に必要か確かめる

   OWASP Top 10:2025のA01は、対策としてCORSの利用を最小限にすることを挙げています。同じオリジンにAPIを置ける構成なら、CORSを使わずに済みます。

2. 許可するオリジンを一覧にする

   OWASPは、Access-Control-Allow-Origin には信頼できる特定のドメインだけを指定し、* や受け取ったオリジンの反射を使わないよう勧めています。null も許可しません。

3. 完全一致で判定し、Vary: Origin を付ける

   前方一致や後方一致ではなく、スキームとポートを含めた文字列全体で比べます。HTTPSのサイトでHTTPのオリジンを許可しないことも大切です。

4. サーバー側の認証と認可を残す

   CORSはブラウザの動作を決めるだけです。Origin ヘッダーはブラウザ以外からなら自由に偽れるので、OWASPは Origin だけをアクセス制御の根拠にしないよう求めています。

よくある質問