目次
APIへ接続したらCORSエラーが出たので、許可ヘッダーを広げて動くようにする。この対処は、何を許したのかが分からないまま、ブラウザーから読める情報の範囲を変えてしまう可能性があります。エラーの解消と、必要な相手だけへ応答を渡すことを分けて考える必要があります。
本稿は2026年10月18日にMDNの公式資料を確認した実務解説です。特定のサービスの被害や新しい脆弱性の速報ではありません。以下のフロントエンドとAPIの構成は仮想例で、確認順序や試験項目は本サイトの提案です。
スポンサーリンク
CORSは応答を読むための境界
オリジンはスキーム、ホスト、ポートの組み合わせです。同じ組織が運用していても、この組み合わせが違えばブラウザー上では別オリジンになることがあります。CORSは、異なるオリジンのスクリプトへ応答を公開する条件を、HTTPヘッダーで伝える仕組みです。
APIへ要求が届くことそのものをすべて防ぐ仕組みではありません。MDNが説明する単純な要求では、プリフライトなしで本来の要求が送られる場合があります。応答をJavaScriptが読めないことと、サーバーが更新を実行しなかったことを同一視しないでください。
さらに、ブラウザー以外のHTTPクライアントは、CORSの許可ヘッダーをアクセス権として強制するわけではありません。APIには認証とデータごとの認可を実装します。CORSを閉じたから非公開APIになった、という判断はできません。
基本となる資料：MDN：Cross-Origin Resource Sharing。
どの画面から何を使うかを先に決める
仮に管理画面と公開サイトが別のホストで、両方からAPIへ接続するとします。公開サイトが匿名の商品一覧を読むことと、管理画面が会員情報を変更することでは、必要な許可が違います。API全体へ同じ緩い設定を配る前に、経路を分けて整理します。
本サイトが提案する台帳には、要求元オリジン、APIのパス、メソッド、Cookieなどの資格情報、応答に含むデータ、担当を記載します。検証用のホストや一時プレビューURLも、なぜ許可するかを判断します。不要になった環境が許可リストへ残らないよう、期限を付けます。
環境変数やプロキシで設定する場合は、実際の本番応答へ反映されたかを確認します。アプリの設定とCDNの設定が重なり、重複したヘッダーや意図しない値が出ることも確認対象です。どこが最終的な許可を生成するかを決めてください。
スポンサーリンク
資格情報付きの応答にワイルドカードを使わない
MDNは、資格情報付きの要求に対するAccess-Control-Allow-Originには、ワイルドカードではなく明示的なオリジンを指定する必要があると説明しています。Access-Control-Allow-Credentialsの設定だけを追加すれば、どの画面からも安全に使えるわけではありません。
Cookieを送るか、応答を読めるか、対象のデータへアクセスできるかは別の判定です。CORSが許可されても、第三者Cookieの制限やSameSiteの条件で認証が期待どおりに働かない場合があります。ブラウザーの保護を回避するためにCookieの範囲をむやみに広げず、正規の構成を先に確認します。
公開してよい匿名データへワイルドカードを使う設計と、個人情報を返す資格情報付きAPIを区別します。同じパスで利用者ごとの情報へ切り替える場合は、キャッシュを含めた公開条件が一致するかを点検してください。
Originを反射するのではなく許可リストで判断する
要求に含まれるOriginを、そのままAccess-Control-Allow-Originへコピーするだけでは、許可する相手を選んだことになりません。本サイトでは、運用上必要な正確なオリジンだけをリストで管理し、一致した場合に限って許可する方針を提案します。
文字列にexample.comが含まれるか、末尾が似ているかという判定は避けます。スキームやポートも含めた意味で解析し、許可する値と比較します。nullも、何となく許可する値にはしません。ファイルやサンドボックス化された文書などの事情を調べ、必要性が説明できる場合に限定して設計します。
多数のテナントを扱う場合、任意のサブドメインを許可する規則を簡単に足す前に、その配下を誰が管理できるかを調べます。放置したホストや外部へ委ねたホストも含め、広い許可が自分の管理範囲と一致するかが重要です。
スポンサーリンク
プリフライトの成功は本処理の許可と別
プリフライトは、一定のクロスオリジン要求の前に、ブラウザーがOPTIONSで許可するメソッドやヘッダーなどを確かめる処理です。その要求へ応答できたことは、実際の更新APIで認証・認可が行われた証拠にはなりません。
本サイトでは、プリフライトの処理と本要求の業務判定を分けて試験する方法を勧めます。前者で許可しないオリジンやヘッダーを拒み、後者では有効な利用者か、対象の所有者か、許される操作かを必ず確かめます。OPTIONSを通すために更新APIの認証まで外さないでください。
必要なカスタムヘッダーを追加した結果プリフライトが起きるなら、そのヘッダーを使う理由も記録します。ブラウザーのエラー文だけから原因を決めず、開発者ツールとサーバー側の記録で、どの段階が失敗したかを切り分けます。
Varyとキャッシュの共有範囲を確認する
MDNは、許可リストに応じてAccess-Control-Allow-Originを動的に変える場合、Vary: Originを応答へ含めることを説明しています。同じURLでも要求元によって応答条件が変わることを、キャッシュへ伝えるためです。
ただしVaryを付ければ個人情報の共有キャッシュまで安全になるわけではありません。利用者ごとの応答をどの条件で保存・再利用するかは別の設計です。CDNやプロキシがどのヘッダーをキャッシュキーへ反映するか、認証付き応答を保存するかを確認します。
仮想の試験では、許可するオリジンAから取得した後、許可しないBから同じURLへ要求し、キャッシュ命中時も意図した結果になるかを確かめます。設定変更の直後だけでなく、古い応答が残る期間も考え、必要な失効手順を決めます。
CORSエラーの調査で秘密を広げない
障害調査では、HTTPステータス、要求元、対象パス、許可ヘッダーの組み合わせをまず確認します。アクセストークンやCookieの値を、スクリーンショットや共有チャットへ貼り付ける必要はありません。秘密を伏せても、構成の違いを調べる情報は残せます。
通信自体が失敗している場合、認証エラーの場合、CORSで応答が読めない場合は対処が異なります。アプリのエラー応答にも必要なCORSヘッダーが付くかを確認すると、正規の画面がエラー内容を判定できない問題を切り分けやすくなります。
「いったん全許可してから戻す」という変更を本番で行うより、検証環境で最小の再現条件を作ることを提案します。一時的な許可を入れた場合は、所有者と撤去時刻を記録し、障害の終了とともに消す条件を作ります。
会員画面と管理画面で許可範囲を分ける例
仮想の構成として、会員サイトと管理サイトが同じAPIを呼ぶ場合を考えます。管理サイトのオリジンを許可したからといって、その場所からの要求がすべて管理者による操作になるわけではありません。管理者向けのデータを返す処理には、CORSとは別に認証と管理権限の確認が必要です。
本サイトは、エンドポイントの用途と許可するオリジンを対応させる表を作ることを勧めます。公開情報だけを返すAPIと個別の契約情報を返すAPIでは、扱う秘密もキャッシュの方針も異なります。共通のミドルウェア一つで全APIへ同じ設定を広げる前に、返す情報を分類します。
開発用のオリジンが本番へ残る問題にも注意します。単にlocalhostを含むかどうかではなく、ポートとスキームを含めた完全な設定が環境ごとに管理されているかを見ます。許可リストの変更を本番のリリースと同じレビュー対象にすると、検証のための一時的な許可が残りにくくなります。
テストでは、応答ヘッダーが付くかと、ブラウザーのスクリプトから本文を読めるかを両方見ます。コマンドラインのHTTPクライアントが内容を取得できることは、ブラウザーのCORS設定が無効な証拠ではありません。逆にブラウザーが本文を読めなくても、状態変更が起きなかったとは限りません。通信と保存結果を分けて確認することが重要です。
| 経路 | 設計上の確認 | 試験の着眼点 |
|---|---|---|
| 公開カタログ | 秘密を含まず公開可能か | 公開範囲とキャッシュに矛盾がないか |
| 会員情報 | セッションと所有者を検証するか | 他人のIDへ変えても読めないか |
| 管理操作 | 管理権限を毎回確認するか | 許可オリジンでも無権限なら拒否するか |
| 開発環境 | 本番とは許可リストを分けるか | 本番に不要なオリジンが残っていないか |
スポンサーリンク
応答を読める条件とデータを返す条件を対で試す
試験には、許可された要求元、有効でない要求元、資格情報なし、期限切れ、別利用者の対象IDなどを組み合わせます。CORSの許可だけでなく、サーバーが返すデータの範囲を確認します。すべて自組織の許可された環境とテストデータで行います。
ブラウザーで失敗しても、サーバー側で更新が実行されたかを必ず別に確認します。必要なCSRF対策や認可がない状態を、読み取りエラーで隠さないためです。逆に、ブラウザー以外のクライアントで要求が成功することだけを、CORSの失敗とみなさないでください。
CORSの管理で目指すのは、必要なフロントエンドへ必要な応答だけを渡すことです。認証、認可、Cookie、キャッシュと役割を分ければ、エラーのたびに許可を広げる運用から、根拠を持って変更できる運用へ移せます。
参考資料
以下は本文の作成時に直接確認した一次資料です。確認日は2026年10月18日です。設定や提供条件は、利用環境に対応した資料も確認してください。
