概要

CORSは、ブラウザが"別オリジンへのHTTPリクエストをどこまで許可するか"を制御する仕組みです。APIが動いているのにフロントエンドからだけ失敗する場合、CORSが原因であることがよくあります。

CORSは何のためにあるか

CORSは、ブラウザ上のJavaScriptが別オリジンのリソースへ自由にアクセスできないようにしつつ、必要な場合だけサーバー側の許可で通信を成立させる仕組みです。

CORSは Cross-Origin Resource Sharing の略です。重要なのは、CORSは HTTPそのものの制限というより、主にブラウザのセキュリティ制約 だという点です。

たとえば次のような構成を考えます。

• フロントエンド: https://app.example.com
• API: https://api.example.com

このとき、ブラウザで動くJavaScriptから見ると、app.example.com と api.example.com は別オリジンです。そのため、APIサーバーが適切に許可しない限り、ブラウザはレスポンスをJavaScriptに渡せません。

オリジンとは何か

CORSを理解するには、まず"オリジン"の意味を正確に押さえる必要があります。オリジンはスキーム、ホスト、ポートの組み合わせです。

次は別オリジンです。

• https://example.com と https://api.example.com（ホストが違う）
• http://example.com と https://example.com（スキームが違う）
• https://example.com と https://example.com:8443（ポートが違う）

同一オリジンポリシー

ブラウザには"同一オリジンポリシー"があり、別オリジンへの自由なアクセスを制限します。CORSはその例外を安全に許可する仕組みです。

同一オリジンポリシーがないと、悪意あるサイトのJavaScriptが別サイトの情報へ勝手にアクセスしやすくなります。CORSは、この制限を完全になくすのではなく、サーバーが明示的に許可したときだけ緩める ための仕組みです。

CORSで何が失敗するのか

CORSエラーは"ネットワーク接続自体が失敗した"とは限りません。サーバーが応答していても、ブラウザがレスポンスをJavaScriptへ渡さないことで失敗に見えることがあります。

よくある誤解は「CORSエラー = APIが落ちている」という理解です。実際には次のようなことが起きます。

1. ブラウザがAPIへリクエストを送る
2. APIサーバーはレスポンスを返す
3. しかしCORSヘッダーが不適切
4. ブラウザがJavaScriptへレスポンスを渡さない

そのため、サーバーログ上は 200 OK でも、フロントエンドでは失敗に見えることがあります。

最も重要なレスポンスヘッダー

CORSでは、サーバーが返すレスポンスヘッダーが中心です。最初に覚えるべきなのは Access-Control-Allow-Origin です。

Access-Control-Allow-Origin

Access-Control-Allow-Origin: https://app.example.com

この場合、https://app.example.com から来たブラウザのJavaScriptは、条件を満たせばレスポンスを利用できます。

すべてを許可する例:

Access-Control-Allow-Origin: *

ただし * は便利ですが、認証付き通信とは相性が悪いため注意が必要です。

Access-Control-Allow-Credentials

Cookieや認証情報を伴うクロスオリジン通信では、Access-Control-Allow-Credentials: true が必要です。この場合、* との組み合わせは使えません。

Access-Control-Allow-Credentials: true

認証付き通信では、Access-Control-Allow-Origin に明示的なオリジン指定が必要です。

単純リクエストとプリフライト

CORSでは、すべてのリクエストが同じ扱いではありません。比較的単純なものはそのまま送られ、条件が複雑なものは先に"プリフライト"が走ります。

ブラウザは、リクエスト内容によって次の2系統で動きます。

• 単純リクエスト
• プリフライト付きリクエスト

単純リクエスト

条件が比較的限定されたリクエストでは、ブラウザは事前確認なしで本リクエストを送り、レスポンスのCORSヘッダーを見て許可判定します。

次のようなケースは単純リクエストとして扱われやすいです。

• GET
• 一部の POST
• 特定のシンプルなヘッダーのみ使用
• Content-Type が限定された値

GET /profile HTTP/1.1
Host: api.example.com
Origin: https://app.example.com

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://app.example.com
Content-Type: application/json

{"name":"Taro"}

プリフライトとは何か

PUT、DELETE、JSON送信、独自ヘッダーなどを使うと、ブラウザは本リクエストの前に OPTIONS で事前確認を行うことがあります。これがプリフライトです。

典型的にプリフライトが発生する条件:

• PUT や DELETE を使う
• Content-Type: application/json
• Authorization ヘッダーを付ける
• カスタムヘッダーを付ける

プリフライトの流れ

プリフライトリクエストの例:

OPTIONS /products HTTP/1.1
Host: api.example.com
Origin: https://app.example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: content-type, authorization

プリフライトレスポンスの例:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 600

Origin ヘッダーの役割

CORS判定では、ブラウザが付与する Origin ヘッダーが重要です。サーバーはこれを見て、どのオリジンから来たかを判断します。

Origin: https://app.example.com

Origin はブラウザが自動で付与します。サーバーはこの値を見て、許可対象なら Access-Control-Allow-Origin を返します。

認証付きCORSでの注意点

Cookieや認証ヘッダーを使うクロスオリジン通信では、通常より条件が厳しくなります。特に * と credentials の組み合わせは使えません。

このとき必要になるもの:

• サーバー側: Access-Control-Allow-Origin: https://app.example.com + Access-Control-Allow-Credentials: true
• クライアント側: fetch(..., { credentials: "include" })

fetch("https://api.example.com/me", {
  method: "GET",
  credentials: "include"
})

Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Credentials: true

* が使えない理由

認証付きCORSでは、どのオリジンでもよいという設定は危険なため、ワイルドカード指定はブラウザに拒否されます。

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

この組み合わせはブラウザに拒否されます。

バックエンドでよくある設定方針

CORSは"とりあえず全部許可"でも動きますが、実務では必要なオリジン、メソッド、ヘッダーに絞る方が安全です。

推奨する方針:

• 許可オリジンを環境ごとに明示する
• 許可メソッドを必要最小限にする
• 許可ヘッダーを明示する
• 認証ありなら Allow-Credentials を適切に使う
• OPTIONS を正しく返す

よくあるCORSエラーの原因

よくある勘違い

CORSはサーバー間通信やCLIでは通常問題になりません。ブラウザでだけ起きる点を忘れると切り分けを誤りやすいです。

curl では成功する、Postmanでも成功する、でもブラウザのフロントエンドからは失敗する、というのはCORSの典型的な現象です。curl や Postman は通常ブラウザのCORS制約を受けないためです。

DevToolsでの確認ポイント

CORS調査では、ブラウザのNetworkタブで OPTIONS、Origin、Access-Control-Allow-* を確認するのが基本です。

{{image:devtools_cors_options}}

見るべきポイント:

1. 本リクエストの前に OPTIONS が飛んでいるか
2. リクエストヘッダーに Origin があるか
3. レスポンスに Access-Control-Allow-Origin があるか
4. 必要に応じて Access-Control-Allow-Methods、Access-Control-Allow-Headers、Access-Control-Allow-Credentials
5. ステータスコードが何か（204、200、403、404、500）

curl でヘッダーを見る例

# 単純リクエスト相当の確認
curl -i \
  -H "Origin: https://app.example.com" \
  https://api.example.com/profile

# プリフライト相当の確認
curl -i -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/products

実務での考え方

CORSはフロントエンド都合の一時的な設定ではなく、公開範囲を決めるセキュリティ設定として扱うべきです。

• 本番では許可オリジンを絞る
• * を安易に使わない
• 認証付き通信の設定を理解して使う
• CORS設定がどこで行われているかを把握する（アプリケーション本体、Webサーバー、API Gateway、CDN / リバースプロキシ）
• エラー時はバックエンドログとブラウザ両方を見る

まとめ

CORSは、ブラウザが別オリジンへのアクセスを安全に制御するための仕組みです。Access-Control-Allow-Origin を中心に、プリフライト、認証付き通信、OPTIONS の扱いを理解すると、フロントエンドとAPIの接続トラブルを切り分けやすくなります。

• CORSは主にブラウザのセキュリティ制約に関係する
• オリジンはスキーム、ホスト、ポートの組み合わせ
• サーバーは Access-Control-Allow-Origin などで許可を返す
• 複雑なリクエストでは OPTIONS のプリフライトが発生する
• 認証付きCORSでは Allow-Credentials と明示的オリジン指定が重要
• curl で成功しても、ブラウザではCORSで失敗することがある
• 調査時はDevToolsで Origin、OPTIONS、Access-Control-Allow-* を確認する