CORSプリフライトの許可範囲とは？危険な設定パターン・許可リストでの設定方法・診断基準

CORSプリフライトの許可範囲とは

CORSプリフライトの許可範囲とは、他オリジンのJavaScriptがAPIへ「単純でない」リクエストを送る前にブラウザが自動で送る OPTIONS リクエスト（プリフライト）に対して、サーバーが Access-Control-Allow-Origin・Access-Control-Allow-Methods・Access-Control-Allow-Headers・Access-Control-Allow-Credentials で許可する範囲のことです。

CORS（オリジン間リソース共有）は、ブラウザの同一オリジンポリシーを、サーバーの明示的な許可がある場合に限って緩める仕組みです。許可の判定を誤ると、利用者が攻撃者のサイトを開いただけで、ログイン中のAPIの応答（個人情報など）を攻撃者のJavaScriptが読み取れるようになります。

セキュリティAIチェッカーのこの項目は、サイト内で見つかったAPI候補に、実在しない外部オリジン（https://miniparse-invalid-origin.example）からのCORSプリフライトを模したOPTIONSリクエストを送り、サーバーがその未許可オリジンに読み取りを許してしまわないかを確認します。

プリフライトの流れ

JavaScriptが他オリジンへ、POST の application/json 送信や Authorization ヘッダー付きのリクエストなど「単純でない」リクエストを送る前に、ブラウザは自動で次のようなOPTIONSを送ります。

OPTIONS /api/data HTTP/1.1
Origin: https://other.example
Access-Control-Request-Method: POST
Access-Control-Request-Headers: authorization,content-type

サーバーは許可する場合に次のように応答し、ブラウザはその内容に合致したときだけ本来のリクエストを送ります。

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://other.example
Access-Control-Allow-Methods: POST
Access-Control-Allow-Headers: authorization,content-type
Access-Control-Max-Age: 600
Vary: Origin

プリフライト自体にはCookie等の認証情報は付きません。認証情報付きの本リクエストを許すには、Access-Control-Allow-Credentials: true が必要です。

CORSプリフライトの許可範囲はなぜ重要なのか

危険な設定パターン

標準・ガイドラインの要求

CORSについてよくある誤解

• 「CORSはサーバーを守る仕組み」：CORSはブラウザが応答の読み取りを制御するもので、サーバーへのリクエスト自体は届きます。CSRF対策の代わりにはなりません。
• 「Originを部分一致で検証すれば十分」：example.lg.jp を含むかどうかで判定すると、example.lg.jp.attacker.example のようなドメインを許してしまいます。完全一致の許可リストで検証します。
• 「* はいつも危険」：認証を伴わない公開データ（オープンデータ等）では、* が正しい設定です。

CORSプリフライトの許可範囲の診断基準（セキュリティAIチェッカー）

取得方法

1. API候補：V2診断で見つかった同一オリジンの /api/ 配下URL、.json のURLなど（最大2件）の先頭1件。候補がなければnaです。
2. 送信内容：メソッド OPTIONS、ヘッダー Origin: https://miniparse-invalid-origin.example、Access-Control-Request-Method: POST、Access-Control-Request-Headers: authorization,content-type。リダイレクトは追跡せず、タイムアウト5秒、本文上限20KB。
3. 応答の Access-Control-Allow-Origin と Access-Control-Allow-Credentials を判定します。

判定条件

• 反射は、Allow-Credentials の有無にかかわらずfailとします。ASVS V3.4.2がOriginの値を使う場合は許可リストでの検証を求めており、反射はその検証がないことを直接示すためです。
• Access-Control-Allow-Origin がない応答は、そのAPIが他オリジンからの読み取りを許していないことを意味するため、安全側としてnaにしています。
• 実際のGET応答での反射は、別項目「任意Originを反射しない」、Vary: Origin の有無は「動的CORSでVary: Originを返す」で判定します。OPTIONSの Allow に並ぶメソッドは「OPTIONSが示す不要・危険なHTTPメソッド」で確認します。

自治体サイトでの判定例

CORSプリフライトの許可範囲が広すぎるとどんなリスクがあるか

• ログイン中データの窃取：Origin反射と認証情報許可が併用されていると、利用者が攻撃者のページを開いただけで、利用者のCookie付きでAPIを呼び出し、予約情報、申請内容、氏名・連絡先などを読み取られます。PortSwiggerのJames Kettle氏は2016年の研究発表で、この種の設定不備が実在の多数のサイトに見られ、暗号資産取引所のAPIキー窃取につながる例があったことを報告しています。
• イントラネット資源の踏み台：認証情報を使わなくても、IPアドレス制限だけで守られた内部APIが * や反射でCORSを許していると、外部サイトが職員のブラウザを経由して内部データを読む攻撃が成立します。
• キャッシュ汚染：Originごとに応答を変えるのに Vary: Origin がないと、CDNが別Origin向けの許可ヘッダーをキャッシュし、正当な利用者で失敗する、または意図しないOriginに許可が出ることがあります。

CORSプリフライトの安全な設定方法（Apache・nginx・Next.js）

基本方針

1. 他オリジンから使わせる必要がないAPIでは、CORSヘッダーを一切返さない。
2. 必要な場合は、許可するOriginを完全一致の許可リストで管理し、一致したときだけその値を返す。
3. Allow-Credentials: true は、Cookie認証が本当に必要な連携だけに限定する。
4. Allow-Methods と Allow-Headers も必要最小限に絞り、Vary: Origin を付ける。

Apache（.htaccess）

<IfModule mod_headers.c>
  SetEnvIf Origin "^https://(www\.example\.lg\.jp|map\.example\.lg\.jp)$" CORS_ALLOW=$0
  Header always set Access-Control-Allow-Origin "%{CORS_ALLOW}e" env=CORS_ALLOW
  Header always set Access-Control-Allow-Methods "GET, POST" env=CORS_ALLOW
  Header always set Access-Control-Allow-Headers "Content-Type" env=CORS_ALLOW
  Header always merge Vary "Origin"
</IfModule>

正規表現は ^ と $ で全体一致にし、ドットはエスケープします。

nginx

map $http_origin $cors_origin {
    default "";
    "https://www.example.lg.jp" $http_origin;
    "https://map.example.lg.jp" $http_origin;
}
server {
    location /api/ {
        add_header Access-Control-Allow-Origin $cors_origin always;
        add_header Vary Origin always;
        if ($request_method = OPTIONS) {
            add_header Access-Control-Allow-Origin $cors_origin always;
            add_header Access-Control-Allow-Methods "GET, POST" always;
            add_header Access-Control-Allow-Headers "Content-Type" always;
            add_header Access-Control-Max-Age 600 always;
            add_header Vary Origin always;
            return 204;
        }
    }
}

値が空の add_header は送信されないため、許可リスト外のOriginにはヘッダーが付きません。

Next.js（Route Handler）

const ALLOWED = new Set(["https://www.example.lg.jp"]);

function corsHeaders(origin: string | null) {
  const headers = new Headers({ Vary: "Origin" });
  if (origin && ALLOWED.has(origin)) {
    headers.set("Access-Control-Allow-Origin", origin);
    headers.set("Access-Control-Allow-Methods", "GET, POST");
    headers.set("Access-Control-Allow-Headers", "Content-Type");
  }
  return headers;
}

export async function OPTIONS(request: Request) {
  return new Response(null, { status: 204, headers: corsHeaders(request.headers.get("origin")) });
}

設定後の確認方法

# 未許可Originでのプリフライト
curl -s -o /dev/null -D - -X OPTIONS https://www.example.lg.jp/api/data \
  -H 'Origin: https://evil.example' \
  -H 'Access-Control-Request-Method: POST' \
  -H 'Access-Control-Request-Headers: content-type' | grep -i '^access-control-'

# null Origin
curl -s -o /dev/null -D - https://www.example.lg.jp/api/data -H 'Origin: null' | grep -i '^access-control-'

未許可Originや null に対して Access-Control-Allow-Origin が返らなければ対応済みです。

サイトを壊さないための注意点

• 許可リストを厳しくすると、地図・予約・外部委託の画面など既存の連携が動かなくなることがあります。適用前に、どのOriginから呼ばれているかをアクセスログの Origin で棚卸ししてください。
• フレームワークの「全Origin許可」設定（例：origin: true、AllowAnyOrigin()）は、開発用の設定が本番に残っていないか確認してください。
• CDNを使う場合は Vary: Origin を必ず付けます。

よくある質問（FAQ）

参考資料

• OWASP ASVS 5.0.0 V3 Web Frontend Security（3.4.2）
• OWASP WSTG Cross Origin Resource Sharing（WSTG-CLNT-07）
• MDN Cross-Origin Resource Sharing (CORS)
• WHATWG Fetch Standard（CORS protocol）
• PortSwigger Web Security Academy: Cross-origin resource sharing (CORS)
• PortSwigger Research: Exploiting CORS misconfigurations for Bitcoins and bounties

「CORSプリフライトの許可範囲」と関連する診断項目

• 任意Originを反射しないhigh
• 動的CORSでVary: Originを返すmedium
• OPTIONSが示す不要・危険なHTTPメソッドmedium
• 危険なCORSワイルドカードがないhigh
• CORSの認証情報設定に矛盾がないhigh