APIは応答したのに読めない？CORSでブラウザーが確認すること

Appli ParkのAPIでは、許可するoriginやHTTPメソッドの指定をしています。 CORSで止まるなら、APIには要求が届かないのでしょうか。 専用の小さな作例で試すと、GETはサーバーへ届いていても、ブラウザーのJavaScriptでは応答を読めない場合がありました。

ページとAPIのoriginが違うときの約束

originは、URLのスキーム、ホスト、ポートの組み合わせです。今回は同じ127.0.0.1でも、画面をポート8772、APIを8773で動かしました。ポートが違うため、別originとして扱われます。 CORSは、別originの応答をページ側のJavaScriptへ渡してよいかを、ブラウザーが応答ヘッダーなどで確認する仕組みです。サーバーが返事をしたことと、その返事をページのプログラムが読めることを分けて考えます。

ダミー応答だけを返す、二つの接続先

API側に、許可ヘッダーを返す/allowと、返さない/denyを用意しました。どちらもGETとPOSTには200で同じダミーのJSONを返すコードです。画面のボタンからfetchで呼び、結果を表示しました。 Cookieは送らず、実サービスのAPIや利用者データも使いません。POSTにも保存処理はありません。確認したいのは、ブラウザーが応答を扱う条件と、実際にAPIへ来た要求の種類です。

GETでは、到達と読取りが分かれた

許可なしのGETも、サーバーの記録には残りました。APIは200の応答を返す実装ですが、許可ヘッダーがないため、画面のfetchは読取り不可になりました。 ここで「CORSがあるから、この要求はサーバーへ到達しない」と考えるのは誤りです。ページでエラーが見えても、サーバー側で処理されたかは別に確認する必要があります。

独自ヘッダー付きPOSTは、先にOPTIONSで確認した

POSTの作例にはX-Article-Demoという独自ヘッダーを付けました。そのため、ブラウザーは本来のPOSTより先にOPTIONSを送り、origin・メソッド・ヘッダーが許可されるかを確認しました。この事前確認がプリフライトです。 許可ありではOPTIONSの後にPOSTが届きました。許可なしではOPTIONSだけで止まり、POSTの記録はありませんでした。今回はOPTIONSに204を返していても、必要な許可ヘッダーがないだけで、この違いが出ました。

POSTという名前だけで、必ずプリフライトになるわけではありません。メソッドやヘッダーなどの条件で決まります。逆にGETでも、独自ヘッダーなどの指定によって事前確認が必要になる場合があります。

実アプリの設定は、許可する相手と項目を選んでいる

Appli ParkのWebConfigは/api以下へ、設定値から読み込んだorigin、許可するメソッド、要求ヘッダーの扱いを指定しています。Retry-Afterをページ側で読める応答ヘッダーとして指定し、資格情報を伴う通信も許可する構成です。 ただし、今回の実験はこのSpring設定そのものを動かす試験ではありません。独立した作例でCORSの基本動作を確認し、実装のどの指定が何を扱うかを読みました。本番の設定値やCookie付き通信の全条件を検証した結果ではありません。

CORSと、誰に操作を許すかは別に考える

CORSは、サーバー側の本人確認や操作権限の代わりにはなりません。ブラウザー以外からの要求もあり、今回のGETのように、読取りを拒否されても要求自体が届く経路もあります。 エラーを調べるときは、要求が届いたか、プリフライトで止まったか、応答をページで読めたかを分けます。「CORSで失敗した」の一言から、どの段階で条件が合わなかったのかへ進むと、確認箇所が絞れます。

参照：Spring Security「CORS」。専用作例のブラウザー表示・サーバー記録と、Appli ParkのWebConfigを確認しました。

確認日：2026年9月22日。実装・検証結果・公式資料は確認時点のものです。