CORSエラーの原因と解決方法｜エラーメッセージ別に解説

CORSエラーは、ブラウザが「別のオリジン（ドメイン・ポート・プロトコルの組み合わせ）のAPIから返ってきたレスポンスを、許可がないためJavaScriptに渡さない」ときに起きるエラーです。解決するには、APIを提供するサーバー側で「このオリジンからのアクセスを許可する」というヘッダーを返すように設定します。

フロントエンドのコードをいくら変えても、基本的にCORSエラーは解決しません。この記事では、CORSの仕組みを最小限おさえたうえで、Chromeに表示されるエラーメッセージ別の原因と対処、主要なフレームワークとnginxの設定例、開発時のプロキシ、安全な設定の注意点までを解説します。

CORSエラーとは：なぜブラウザが止めるのか

ブラウザには、同一オリジンポリシーという安全のためのルールがあります。あるWebページのJavaScriptは、原則として同じオリジンのサーバーからのレスポンスしか読み取れません。

オリジンは、「プロトコル（スキーム）・ホスト・ポート」の3つの組み合わせです。

このルールがあることで、悪意のあるサイトのJavaScriptが、ログイン中のあなたの権限で別のサイトのデータを読み取ることを防いでいます。

CORS（Cross-Origin Resource Sharing）は、このルールをサーバー側が明示的に緩める仕組みです。サーバーが「このオリジンからなら読んでよい」とヘッダーで伝えると、ブラウザはレスポンスをJavaScriptに渡します。

curlやPostmanでは成功する理由

CORSはブラウザが行うチェックです。curlやPostman、サーバー同士の通信では、CORSのチェックは行われません。「curlでは動くのに、ブラウザだけエラーになる」のは、CORSの典型的な症状です。

また、多くの場合リクエスト自体はサーバーに届いており、サーバーはレスポンスを返しています。ブラウザが、そのレスポンスをJavaScriptに渡すのを止めているのです。

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

CORSには、2種類の流れがあります。どちらになるかで、必要な設定が変わります。

単純リクエスト

次の条件をすべて満たすリクエストは、そのまま送信されます。

• メソッドが GET・HEAD・POST のいずれか
• 独自のヘッダー（Authorizationなど）を付けていない
• Content-Typeが application/x-www-form-urlencoded・multipart/form-data・text/plain のいずれか

サーバーのレスポンスに Access-Control-Allow-Origin があれば、ブラウザはJavaScriptに結果を渡します。

プリフライトリクエスト

条件を1つでも満たさない場合、ブラウザは本番のリクエストの前に、OPTIONSメソッドで「このリクエストを送ってよいか」を問い合わせます。これがプリフライトリクエストです。

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

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

JSONを送るPOST（Content-Type: application/json）や、Authorizationヘッダーを付けたリクエストは、プリフライトになります。現代のWebアプリのAPI呼び出しは、ほとんどがこちらです。

CORSのヘッダー一覧

エラーメッセージ別の原因と対処

Chromeの開発者ツールのコンソールに表示されるメッセージから、原因を特定できます。

No 'Access-Control-Allow-Origin' header is present on the requested resource.

Access to fetch at 'https://api.example.com/orders' from origin 'https://app.example.com'
has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present
on the requested resource.

原因：レスポンスに Access-Control-Allow-Origin ヘッダーがない。

対処：APIサーバーで、フロントエンドのオリジンを許可する設定を追加します。設定したはずなのに出る場合は、次の2点を確認します。

• エラーレスポンス（401・404・500など）にもヘッダーが付いているか。多くのサーバーやフレームワークは、エラー時にCORSのヘッダーを付けません。その結果、本当の原因（認証エラーやサーバーエラー）が、CORSエラーとして見えてしまいます。開発者ツールの「Network」タブで、実際のステータスコードを確認してください
• URLが間違っていないか。存在しないURLへのリクエストが404になり、上記の理由でCORSエラーに見えることがあります

Response to preflight request doesn't pass access control check: It does not have HTTP ok status.

原因：プリフライト（OPTIONSリクエスト）に対して、サーバーが 200番台以外（401・403・404・405など）を返している。

対処：よくある原因は次のとおりです。

• 認証のチェックが、OPTIONSリクエストにもかかっている。プリフライトにはAuthorizationヘッダーやCookieが付かないため、認証が必要な設定だと401になります。OPTIONSは認証の対象外にします
• OPTIONSメソッドのルートがない（404・405になる）
• WAFやAPIゲートウェイが、OPTIONSを拒否している

The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'.

原因：Cookieなどの認証情報を送る設定（credentials: 'include' や withCredentials: true）で、サーバーが Access-Control-Allow-Origin: * を返している。

対処：認証情報を送る場合は、ワイルドカード（*）は使えません。許可するオリジンを具体的に指定し、あわせて Access-Control-Allow-Credentials: true を返します。

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-Credentials: true を返します。

Request header field authorization is not allowed by Access-Control-Allow-Headers in preflight response.

原因：リクエストに付けたヘッダー（この例ではAuthorization）が、プリフライトのレスポンスで許可されていない。

対処：Access-Control-Allow-Headers に、そのヘッダー名を追加します。

Method PUT is not allowed by Access-Control-Allow-Methods in preflight response.

原因：使ったメソッドが、プリフライトのレスポンスで許可されていない。

対処：Access-Control-Allow-Methods に、そのメソッドを追加します。

The 'Access-Control-Allow-Origin' header contains multiple values ', ', but only one is allowed.

原因：ヘッダーが2回付いている。アプリケーションとnginx（またはAPIゲートウェイ）の両方でCORSの設定をしている場合によく起きます。

対処：CORSのヘッダーを付ける場所を1か所に統一します。

The 'Access-Control-Allow-Origin' header has a value 'https://a.example.com' that is not equal to the supplied origin.

原因：許可しているオリジンと、実際のオリジンが違う。http と https、www の有無、ポート番号、末尾のスラッシュの違いがよくある原因です。

対処：開発者ツールで、リクエストの Origin ヘッダーの値を確認し、完全に一致する値を許可します（末尾のスラッシュは付けません）。

Redirect is not allowed for a preflight request.

原因：プリフライトのリクエストが、リダイレクト（301・302など）されている。httpからhttpsへの転送や、末尾のスラッシュを付ける転送でよく起きます。

対処：フロントエンドから、リダイレクトされない最終的なURLを直接呼び出します。

サーバー側の設定例

どの例も、https://app.example.com からのアクセスを、Cookie付きで許可する設定です。

Express（Node.js）

import cors from "cors";

app.use(cors({
  origin: ["https://app.example.com"],
  credentials: true,
}));

Spring Boot

@Configuration
public class CorsConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/api/**")
                .allowedOrigins("https://app.example.com")
                .allowedMethods("GET", "POST", "PUT", "DELETE")
                .allowedHeaders("*")
                .allowCredentials(true);
    }
}

Spring Securityを使っている場合は、セキュリティの設定でもCORSを有効にする必要があります（有効にしないと、プリフライトが認証で拒否されます）。

FastAPI（Python）

from fastapi.middleware.cors import CORSMiddleware

app.add_middleware(
    CORSMiddleware,
    allow_origins=["https://app.example.com"],
    allow_credentials=True,
    allow_methods=["*"],
    allow_headers=["*"],
)

nginx

location /api/ {
    if ($request_method = OPTIONS) {
        add_header Access-Control-Allow-Origin "https://app.example.com" always;
        add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE" always;
        add_header Access-Control-Allow-Headers "Authorization, Content-Type" always;
        add_header Access-Control-Allow-Credentials "true" always;
        add_header Access-Control-Max-Age 600 always;
        return 204;
    }
    add_header Access-Control-Allow-Origin "https://app.example.com" always;
    add_header Access-Control-Allow-Credentials "true" always;
    add_header Vary Origin always;
    proxy_pass http://backend;
}

nginxの add_header は、既定では成功時のレスポンスにしか付きません。always を付けると、エラーのレスポンスにもヘッダーが付き、本当のエラー内容をフロントエンドで確認できるようになります。

開発環境では、プロキシで同じオリジンにする

開発中は、フロントエンド（例：localhost:5173）とAPI（例：localhost:8080）のポートが違うため、CORSエラーが起きがちです。開発サーバーのプロキシ機能を使うと、ブラウザからは同じオリジンに見えるため、CORSの設定なしで開発できます。

// vite.config.js
export default {
  server: {
    proxy: {
      "/api": { target: "http://localhost:8080", changeOrigin: true },
    },
  },
};

フロントエンドからは fetch("/api/orders") のように、オリジンを付けずに呼び出します。本番環境でも、フロントエンドとAPIを同じドメインの配下に置く（リバースプロキシで振り分ける）構成にすれば、CORS自体が不要になります。

やってはいけない「解決方法」

安全な設定のポイント

• 許可するオリジンは、一覧で具体的に指定する。オリジンを動的に判定する場合は、許可リストと照合してから返す
• オリジンによって返す値を変える場合は、Vary: Origin を付ける。付けないと、CDNなどのキャッシュが別のオリジン向けのレスポンスを返すことがある
• * を使ってよいのは、認証なしで誰でも使える公開APIに限る

CORSはCSRF対策ではない

CORSは、「レスポンスをJavaScriptに渡すかどうか」を制御する仕組みです。単純リクエストは、CORSの設定に関係なくサーバーに届き、処理されます。フォームからのPOSTのような、利用者の意図しない操作（CSRF）を防ぐには、CSRFトークンやCookieのSameSite属性など、別の対策が必要です。

Cookieを送る場合の追加の注意点

別のオリジンのAPIにCookieを送るには、CORSの設定に加えて、Cookie自体の設定も必要です。

• フロントエンドで credentials: "include"（axiosなら withCredentials: true）を指定する
• サーバーは、具体的なオリジン＋Access-Control-Allow-Credentials: true を返す
• サイトをまたいでCookieを送る場合は、Cookieに SameSite=None; Secure が必要（HTTPSが前提）

ブラウザによっては、サイトをまたぐCookie（サードパーティCookie）自体を制限しています。フロントエンドとAPIを同じサイト（例：app.example.comとapi.example.com）に置く構成にしておくと、こうした影響を受けにくくなります。

よくある質問

Q. CORSエラーはフロントエンドで解決できますか？ A. 基本的にはできません。ブラウザは、サーバーが返すヘッダーを見て判断するため、APIサーバー側の設定が必要です。自分で管理していない外部APIの場合は、自分のサーバーを経由して呼び出す（サーバー間の通信にはCORSが関係しない）方法をとります。

Q. 画像やフォント、iframeでもCORSは関係しますか？ A. <img> タグで画像を表示するだけなら関係しません。ただし、画像をCanvasに描いて読み取る場合や、Webフォントを別のオリジンから読み込む場合は、CORSの設定が必要です。

Q. 設定を直したのに、エラーが変わりません。 A. プリフライトの結果がキャッシュされている（Access-Control-Max-Age）、またはCDNにレスポンスがキャッシュされている可能性があります。開発者ツールでキャッシュを無効にして再読み込みするか、CDNのキャッシュを削除してください。

Q. localhostで開発していると、なぜCORSエラーになるのですか？ A. フロントエンドとAPIでポート番号が違うと、別のオリジンになるためです。開発サーバーのプロキシを使うか、APIでlocalhostのオリジンを許可します（本番の設定に開発用のオリジンを残さないよう注意します）。

まとめ

• CORSエラーは、ブラウザが別オリジンのレスポンスをJavaScriptに渡さないために起きる。curlでは起きない
• 解決するのはAPIサーバー側。許可するオリジンをヘッダーで返す
• JSONのPOSTやAuthorizationヘッダー付きはプリフライト（OPTIONS）になる。OPTIONSを認証の対象外に
• エラー時にヘッダーがないと、本当のエラーがCORSエラーに見える。Networkタブでステータスを確認する
• Cookieを送るなら、* は使えない。具体的なオリジン＋Allow-Credentials: true＋SameSite=None; Secure
• 開発時はプロキシで同じオリジンにする。no-cors やOriginの丸ごと許可は使わない

株式会社RJCでは、エラーメッセージの意味を仕組みから理解することを大切にしています。こうした知識を仲間と共有しながら、一緒に成長を楽しんでいます。

株式会社RJC ― SI事業・SES事業・AI駆動開発。未経験からエンジニアに育てるのが得意な会社です。