ネットワーク/HTTP
CORS Checker / Explainer
ブラウザがクロスオリジンリクエストを許可するかどうかを段階的に説明します — simple/preflight分類、レスポンスのAccess-Control-*ヘッダーのチェック、まとめ。
1行に1つ、「名前」または「名前: 値」— 値は分類に影響しません。
DevToolsのNetworkタブ(レスポンス自体のヘッダーまたはpreflight OPTIONS)、あるいはcurl -Iから取得してください。
CORS (Cross-Origin Resource Sharing) is a browser mechanism that decides whether JavaScript from one site is allowed to read a response from a server on a different domain. This tool walks through, step by step, whether a specific request will succeed and which Access-Control-* headers it needs.
How to use it
- Provide the method, the request's origin, and the server's response headers (Access-Control-Allow-Origin, etc.) and the tool determines whether the browser will let the request through.
- The "simple" vs. "preflight" classification shows whether the browser will first send an OPTIONS preflight request before the actual one.
- The summary gives the exact reason for a failure when a request would be blocked — faster than parsing the browser console's error message.
Common uses
- Debugging the classic "has been blocked by CORS policy" error with a step-by-step explanation of what's missing, instead of guessing.
- Checking a backend's CORS configuration before the frontend and API end up on separate domains in production.
- Understanding why a request with credentials: include is rejected even though Access-Control-Allow-Origin looks correct.
Things to keep in mind
CORS protects the user's browser, not the server — the restriction only applies to requests made from page JavaScript in a browser, not to requests from curl, Postman, or server-to-server calls.
Access-Control-Allow-Origin: * is incompatible with credentials: include — for requests carrying cookies or authorization, the server must return a specific origin instead of a wildcard.
よくある質問
サーバーが正常に応答したのに、なぜリクエストがCORSエラーで失敗するのですか?
CORSはサーバーではなくブラウザによって適用されます — レスポンスにリクエスト元のオリジンと一致するAccess-Control-Allow-Originヘッダーがない場合、リクエスト自体は完了していても、ブラウザはJavaScriptがレスポンスを読み取るのをブロックします。
シンプルリクエストとプリフライトリクエストの違いは何ですか?
シンプルリクエスト(標準ヘッダーを使った基本的なGET/POST)はそのまま通過しますが、カスタムヘッダー、他のメソッド、特定のコンテンツタイプを持つリクエストは、実際のリクエストを送信する前に権限を確認するためのプリフライトOPTIONSリクエストを最初にトリガーします。
ここでCORSヘッダーを確認すると、データがサーバーに送信されますか?
このツールは、あなたが提供したヘッダーを検査するか、ブラウザから直接取得します — 中間サーバーがリクエストデータを保存することはありません。
CORSはAPIを悪意あるリクエストから保護しますか?
いいえ。CORSはブラウザ内のJavaScriptが読み取れる内容を制限するだけです — curl、Postman、バックエンドスクリプトを使う攻撃者は完全に迂回できるため、本物の認証・認可はサーバー側で実装する必要があります。
なぜAccess-Control-Allow-Origin: * はcredentials: includeと一緒に使えないのですか?
仕様はセキュリティ上の理由でこの組み合わせを意図的に禁止しています — credentials(cookieや認証ヘッダー)を任意のoriginを受け入れるワイルドカードと一緒に許可すると重大なセキュリティ上の欠陥になるため、credentialsを使う場合サーバーは正確なoriginを返す必要があります。