よくあるCORSエラーのデバッグ

CORSエラーのステップバイステップデバッグ

CORSエラーはブラウザコンソールに表示されますが、セキュリティ上の理由から実際のレスポンスはJavaScriptから隠されています。体系的に診断する方法を説明します。

ステップ1: エラーメッセージを読む

エラーメッセージ	考えられる原因
"No 'Access-Control-Allow-Origin' header"	サーバーがCORSヘッダーをまったく送信していない
"must not be the wildcard '*' when credentials"	オリジンが*だがクライアントがcredentials: includeを使用
"is not in the list of allowed origins"	オリジンの不一致（プロトコル、ポート、末尾のスラッシュを確認）
"Method PUT is not allowed"	Access-Control-Allow-Methodsにメソッドがない
"Request header field X-Api-Key is not allowed"	Access-Control-Allow-Headersにヘッダーがない

ステップ2: ネットワークタブを検査

1. DevTools > ネットワークを開く。
2. OPTIONSリクエスト（存在する場合）を見つけ、ステータスコードとレスポンスヘッダーを確認。
3. 実際のリクエスト（GET/POST等）を見つけ、レスポンスヘッダーにAccess-Control-Allow-Originがあるか確認。
4. Originリクエストヘッダーがサーバーの期待値と一致するか確認。

ステップ3: curlでテスト

curl -v -X OPTIONS \
  -H "Origin: https://app.example.com" \
  -H "Access-Control-Request-Method: POST" \
  -H "Access-Control-Request-Headers: Content-Type, Authorization" \
  https://api.example.com/data

ブラウザの干渉なしにサーバーが返すヘッダーを正確に確認できます。

ステップ4: よくある問題を確認

• プロトコルの不一致: http:// vs https:// — オリジンは正確に一致する必要があります。
• ポートの不一致: localhost:3000 vs localhost:8080 — 異なるポートは異なるオリジン。
• 末尾のスラッシュ: https://example.com vs https://example.com/ — 一部のサーバーは厳格。
• サブドメイン: www.example.com vs example.com — これらは異なるオリジン。
• ミドルウェアの順序: CORSミドルウェアは認証ミドルウェアの前に実行する必要があります。
• リバースプロキシがヘッダーを除去: プロキシ（Nginx、CloudFront、ALB）がCORSヘッダーを除去していないか確認。

ステップ5: 修正を確認

修正を適用した後、ブラウザをハードリフレッシュ（Ctrl+Shift+R）してプリフライトキャッシュをクリアし、再度テストします。