CORSテスターオンライン：クロスオリジンリソース共有の問題を診断
· 12分で読めます
目次
CORSとその重要性を理解する
クロスオリジンリソース共有（CORS）は、Webブラウザに実装されているセキュリティメカニズムで、Webアプリケーションが異なるオリジンからリソースをリクエストする方法を制御します。クラブの用心棒のようなもので、特定のルールに基づいて誰を入れて誰を入れないかを決定します。
デフォルトでは、ブラウザは同一オリジンポリシー（SOP）を適用し、あるドメインで実行されているJavaScriptが別のドメインのリソースにアクセスすることを防ぎます。これは、悪意のあるスクリプトからユーザーを保護する基本的なセキュリティ機能です。しかし、最近のWebアプリケーションは、異なるドメインでホストされているAPIやサービスと通信する必要があることが多く、そこでCORSが登場します。
CORSは、サーバーがブラウザに「はい、この特定のWebサイトが私のリソースにアクセスしても大丈夫です」と伝えるための標準化された方法を提供します。適切なCORS設定がないと、正当なクロスオリジンリクエストがブロックされ、Webアプリケーションの機能が壊れてしまいます。
プロのヒント：CORSはブラウザが強制するセキュリティ機能です。cURLやPostmanのようなツールはブラウザではないため、CORS問題に遭遇しません。常に実際のブラウザ環境でCORS設定をテストしてください。
実際のシナリオを考えてみましょう：フロントエンドがhttps://myshop.comでホストされているEコマースプラットフォームを構築していますが、商品在庫APIはhttps://api.inventory-service.comにあります。CORSヘッダーがないと、フロントエンドのJavaScriptは商品データを取得できず、顧客は空の棚を見つめることになります。
CORSは以下の場合に特に重要になります：
- フロントエンドが直接アクセスする必要があるサードパーティAPI
- 異なるサービスが異なるドメインで実行されるマイクロサービスアーキテクチャ
- 異なるオリジンからアセットを提供するコンテンツ配信ネットワーク（CDN）
- バックエンドAPIと通信するシングルページアプリケーション（SPA）
- 外部ドメインから読み込まれるWebフォント、画像、その他のリソース
CORSの仕組み：技術的な詳細
CORSが内部でどのように機能するかを理解することで、問題をより効果的に診断できます。CORSメカニズムには、シンプルリクエストとプリフライトリクエストの2種類のリクエストがあります。
シンプルリクエスト
シンプルリクエストは、以下のすべての条件を満たすリクエストです：
- 次のHTTPメソッドのいずれかを使用：GET、HEAD、またはPOST
- Accept、Accept-Language、Content-Language、Content-TypeなどのCORS安全ヘッダーのみを含む
- Content-Typeを使用する場合、application/x-www-form-urlencoded、multipart/form-data、またはtext/plainである必要がある
シンプルリクエストの場合、ブラウザはOriginヘッダーを付けてリクエストを直接送信します。サーバーは、オリジンが許可されているかどうかを示すAccess-Control-Allow-Originヘッダーで応答します。ヘッダーがリクエストしているオリジンと一致する（または*に設定されている）場合、ブラウザはJavaScriptコードがレスポンスを読み取ることを許可します。
プリフライトリクエスト
シンプルリクエストの基準を満たさないリクエストは、プリフライトリクエストをトリガーします。これは、実際のリクエストの前にブラウザが送信するOPTIONSリクエストで、CORSプロトコルが理解され、実際のリクエストが安全に送信できるかどうかを確認します。
プリフライトリクエストには次のようなヘッダーが含まれます：
Access-Control-Request-Method：実際のリクエストのHTTPメソッドAccess-Control-Request-Headers：実際のリクエストと一緒に送信されるカスタムヘッダーOrigin：リクエストを行っているオリジン
サーバーは、何が許可されているかを示す適切なCORSヘッダーでプリフライトに応答する必要があります。プリフライトが成功した場合にのみ、ブラウザは実際のリクエストを送信します。
クイックヒント：プリフライトリクエストはパフォーマンスに影響を与える可能性があります。Access-Control-Max-Ageヘッダーを使用してプリフライトレスポンスをキャッシュし、サーバーが処理する必要があるOPTIONSリクエストの数を減らしてください。
よくあるCORSの問題とエラーメッセージ
CORSエラーは、開発者が遭遇する最もイライラする問題の1つです。最も一般的な問題とその実際の意味を分解してみましょう。
Access-Control-Allow-Originヘッダーの欠落
これは最も一般的なCORSエラーです。ブラウザコンソールには次のように表示されます：
Access to fetch at 'https://api.example.com/data' from origin 'https://myapp.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
これは、サーバーがレスポンスに必要なCORSヘッダーを含めなかったことを意味します。修正は簡単です：特定のオリジンまたはパブリックAPIの場合は*を指定してAccess-Control-Allow-Originヘッダーを送信するようにサーバーを設定します。
不正なHTTPメソッド
サーバーが明示的に許可していないHTTPメソッドを使用しようとすると、次のようなエラーが表示されます：
Access to fetch at 'https://api.example.com/data' from origin 'https://myapp.com' has been blocked by CORS policy: Method PUT is not allowed by Access-Control-Allow-Methods in preflight response.
これはプリフライトフェーズで発生します。サーバーはAccess-Control-Allow-MethodsヘッダーにHTTPメソッドを含める必要があります。
認証情報がサポートされていない
Cookieや認証ヘッダーを送信しようとしているが、サーバーがそれに対応していない場合、次のエラーが発生します：
Access to fetch at 'https://api.example.com/data' from origin 'https://myapp.com' has been blocked by CORS policy: The value of the 'Access-Control-Allow-Credentials' header in the response is '' which must be 'true' when the request's credentials mode is 'include'.
これを修正するには、サーバーがAccess-Control-Allow-Credentials: trueを送信する必要があり、重要なことに、認証情報が関与する場合はAccess-Control-Allow-Origin: *を使用できません—正確なオリジンを指定する必要があります。
カスタムヘッダーが許可されていない
最近のアプリケーションは、APIキー、認証トークン、その他のメタデータにカスタムヘッダーを使用することがよくあります。これらが明示的に許可されていない場合、次のように表示されます：
Request header field x-api-key is not allowed by Access-Control-Allow-Headers in preflight response.
解決策は、Access-Control-Allow-Headersレスポンスヘッダーにカスタムヘッダーを含めることです。
| エラータイプ | 一般的な原因 | クイック修正 |
|---|---|---|
| Access-Control-Allow-Originなし | サーバーがCORS用に設定されていない | サーバーレスポンスにヘッダーを追加 |
| メソッドが許可されていない | HTTPメソッドが許可リストにない | Access-Control-Allow-Methodsを更新 |
| 認証情報がサポートされていない | 認証情報ヘッダーが欠落 | Access-Control-Allow-Credentials: trueを設定 |
| ヘッダーが許可されていない | カスタムヘッダーがホワイトリストに登録されていない | Access-Control-Allow-Headersに追加 |
| 認証情報付きワイルドカード | 認証情報モードで*を使用 | *の代わりに正確なオリジンを指定 |
CORSテスターを効果的に使用する
CORSテスターは、コードを書かずにクロスオリジンの問題を診断するための非常に貴重なツールです。ブラウザのリクエストをシミュレートし、送受信されているCORSヘッダーを正確に表示します。CORSテスターを使用して、問題を迅速に診断できます。
優れたCORSテスターが行うべきこと
効果的なCORSテストツールは以下を提供する必要があります：
- ターゲットURLとオリジンを指定する機能
- 異なるHTTPメソッド（GET、POST、PUT、DELETEなど）を選択するオプション
- 特定のシナリオをテストするためのカスタムヘッダー設定
- リクエストヘッダーとレスポンスヘッダーの両方の明確な表示
- CORSチェックが成功したか失敗したかの表示
- 何が問題だったかを説明する詳細なエラーメッセージ
ステップバイステップのテストプロセス
CORSテスターを効果的に使用する方法は次のとおりです：
- テストしたいAPIエンドポイントURLを入力
- リクエストを行うオリジンを指定（フロントエンドドメイン）
- アプリケーションが使用するHTTPメソッドを選択
- アプリケーションが送信するカスタムヘッダーを追加（AuthorizationやX-API-Keyなど）
- テストを実行して結果を確認
- レスポンスヘッダーを確認して、どのようなCORSポリシーが設定されているかを確認
- サーバーで設定する必要がある欠落または不正なヘッダーを特定
プロのヒント：本番アプリケーションが使用する正確なオリジンで常にテストしてください。一部のサーバーには、localhostでは機能するが本番ドメインでは失敗するオリジン固有のCORS設定があります。
テスト結果の解釈
CORSテストを実行する際は、次の重要な指標に注意してください：
- プリフライトステータス：OPTIONSリクエストは成功しましたか？そうでない場合、サーバーがプリフライトリクエストを正しく処理していない可能性があります。
- Access-Control-Allow-Originの値：オリジンと一致していますか、それとも*に設定されていますか？一致しない場合、リクエストは失敗します。
- 許可されたメソッド：意図したHTTPメソッドがAccess-Control-Allow-Methodsにリストされていますか？
- 許可されたヘッダー：すべてのカスタムヘッダーがAccess-Control-Allow-Headersに含まれていますか？
- 認証情報のサポート：Cookieを送信する必要がある場合、Access-Control-Allow-Credentialsがtrueに設定されていますか？
HTTPヘッダーアナライザーを使用して、送受信されているすべてのヘッダーの詳細な内訳を取得することもできます。これはCORSテストを完璧に補完します。
CORS問題を診断する実践例
例1：ソーシャルメディア統合
複数のプラットフォームからの投稿を集約するソーシャルメディアダッシュボードを構築しているとしましょう。https://dashboard.example.comのフロントエンドは、https://api.socialmedia.comからデータを取得する必要があります。
新しい投稿を作成するためにPOSTリクエストを行っていますが、CORSエラーが発生し続けています。診断方法は次のとおりです：
- CORSテスターを開き、
https://api.socialmedia.com/postsを入力 - オリジンを
https://dashboard.example.comに設定 - メソッドとしてPOSTを選択
- Content-Typeヘッダーを追加：
application/json - Authorizationヘッダーを追加：
Bearer your-token-here - テストを実行
テストの結果、サーバーがGETリクエストのみを許可していることが明らかになりました。Access-Control-Allow-MethodsヘッダーにはGET, HEAD, OPTIONSと表示されています。POSTリクエストを有効にするためにAPIプロバイダーに連絡するか、投稿を作成するための別のエンドポイントがあるかどうかを確認する必要があります。
例2：Eコマース在庫システム
https://shop.example.comのEコマースサイトは、https://inventory.example.comから在庫データを取得します。APIは、どの店舗がリクエストを行っているかを識別するために、カスタムヘッダーX-Shop-IDを必要とします。
テストの結果、次のエラーが表示されます：「Request header field x-shop-id is not allowed b